Most embedded devices nowadays are implemented using an operating system of some kind. This has not always been the case and need not be today. Historically, using an OS was less common, mainly because the applications were less complex and CPUs less powerful.

Some thought is needed, at an early stage in a project, to determine which OS to use (or whether to use one at all) ...

I started thinking about this when a potential customer asked me for help. He was planning to select an embedded OS and wanted a process - maybe something like a flowchart - to help him make a decision. I gave this some thought and then told him the bad news: there is no simple process to make the selection; there are just too many interrelated factors. I offered to work through his needs with him to help arrive at a conclusion and, as a result, I developed a talk on the subject which I have used and evolved over time.

The first thing to decide is whether you actually need an OS at all. If you have sufficient CPU power, the answer is probably yes. For a complex application, this conclusion is fairly obvious.

For a simple application, an OS may seem quite unnecessary. However, the reason why deploying one may be wise is future maintainability. The application may be simple today, but more capabilities may need to be added in the future. An OS provides a scalable platform on which to extend the application in a managed way. Without the OS environment, adding functionality to an application has a higher chance of breaking what is already there.

It is interesting to observe, however, that some applications today use an OS unnecessarily for the simple reason that the developers are completely unable to conceive of the idea of implementing code on "bare metal" with no underlying OS.

Having concluded that you will use an OS, there is the question of sourcing it. At the highest level, there are three options: implement it in-house, download and deploy a "free" OS of some kind, or obtain a commercial OS from a reputable supplier. As I work for a vendor of embedded operating systems, there are no prizes for guessing which path I would suggest.

If you decide not to write the OS yourself, the final step is the actual selection of an OS from the wide variety on offer. This is quite a complex decision, which should be based on technical and commercial parameters and also on the experience of yourself, your team and other developers in your network. This experience should not be confined to knowing the API but encompass considerations like the quality of technical support and documentation.