Choosing an embedded operating system

Colin Walls, embedded software technologist, has over twenty-five years of experience. A frequent presenter at conferences and seminars, and author of numerous technical articles and books on embedded software, Colin is a member the Mentor Embedded Systems Division.

Almost all modern embedded systems are built using an operating system (OS) of some sort. This means that the selection of that OS tends to occur early in the design process. Many developers find this selection process challenging. How do you choose an OS for your specific application?

This was the question posed to me by a potential customer not so long ago. He was after some process – some methodical guidance – to drive his selection process. I explained that this really was not possible – there are too many interrelated factors to render anything like that in a flowchart. The process is all about considering a wide selection of factors, asking the right questions and weighing up the answers. That is where I can provide guidance.

Do you need an OS at all?

For many embedded applications, it is obvious that an OS is needed. If the application is complex and running on a high-end processor, it is almost certain that an OS would be beneficial. At the other end of the scale, simple software running on a low-end chip has no need of an OS at all. There are two other possibilities: complex software on a low-end CPU; and simple software on a complex processor. In both these cases, it may seem that an OS would not provide much advantage and may indeed get in the way of efficiency. However, architecting your code around a multi-tasking model is a great way to make it scalable, thus minimizing work when, at some future point, you move to a more powerful device and/or need to add further complexity to your application.

Figure 1. Is an embedded operating system necessary? (Mentor)

Where can you get an OS?

Broadly there are three ways to obtain an embedded operating system:

• Write one yourself.
• Utilize a ‘free’ or open source product.
• Purchase or license a product from a commercial vendor

Option (1) is very rarely a good choice, as it is unlikely that your specific needs are so specialized that they are not addressed by an existing product. It is unusual for ‘reinventing the wheel’ to ever be a wise decision. The only likely exception might be writing an OS as an academic exercise to fully appreciate how a product works. Option (2) looks attractive, as everyone likes something for free, except that there are real costs to consider: implementation and support.

Selection criteria

The choice of an OS is driven by a series of questions that you might ask yourself or others. It is easy to imagine that this is all about the technicalities of an OS and, indeed, these issues dominate the process. However, commercial considerations, like cost, need to be addressed, and factors like personal experience cannot be ignored.

Technical factors

The technical facets of an OS dominate the selection process. These matters need to be completely clear before other parameters are considered:

• Is your application real time?
• Is memory size limited?
• Is CPU power limited?
• Is device power consumption an issue?
• Does your system have obscure or custom peripherals?
• Do you have a memory management unit (MMU)?
• Is application security an issue?
• Does your application require safety certification?

Commercial factors

Although engineers enjoy the technical challenges of embedded software development, such projects are subject to commercial considerations. Everything comes down to money. Implementing an OS costs money, however it is obtained.

• An in-house development obviously costs money.
• A commercial product has a price.
• Open source is not ‘free’. There are implementation costs and ongoing maintenance

Commercial OS products are offered with various business models. For example, there may a low starting payment and ongoing royalties on each unit shipped. Or there could be a larger up-front charge but no ongoing royalties. An acceptable model depends on the selling price and the projected shipping volume.

Other considerations

An easily overlooked aspect of the OS selection process is that you should draw on past experience. You and your team may have used one or more OSes before, and this may have a significant influence.

For example, a detailed knowledge of an OS’s API takes some time to acquire. Being able to reuse this knowledge is a great benefit. If the API is proprietary, this may be a strong pointer to a particular product. If the API is a standard, like POSIX, you still have a choice. Of course, a bad experience with a confusing and inflexible API may have the opposite effect!

Experience with working with a particular vendor is another factor. Was their technical support any good? Was the documentation up to scratch? Was source code available and well commented?

Conclusions

Overall, it may be seen that there is no really simple answer to the question of selecting an embedded OS. There are numerous interlinked factors. It is essential to not just focus on technical considerations, but also consider commercial matters and past experience.

For desktop computers, there is a choice of about four operating systems. In the embedded world there are dozens, at least. Why is that? Simply put, desktop computers are all much the same, but every embedded system is different. This difference is both technical and commercial. Hence the need for the detailed selection process.

For more information on making IoT device implementation straightforward visit our Mentor Embedded IoT Framework page.