How to select your embedded systems operating system: OS characteristics

Costs and the business aspects of building products are key criteria, but attributes like available libraries, security, and maintainability also play an essential role.

Embedded system developers have a wide range of operating systems available to them today. Of course, the most straightforward operating system is to have no operating system! However, many systems today are complex, connected systems where an operating system might be required. When required, developers will often look to use a real-time operating system (RTOS) or Linux to help them manage the complexity. Unfortunately, it’s not always clear-cut how to choose between bare metal, RTOS, or Linux. Each option has its advantages and disadvantages.

This post will explore system characteristics you should consider for selecting your operating system. Then in the next article, we will walk through when it makes the most sense to use each operating system.

The Product’s Lifetime Costs

Selecting the operating system for your embedded system starts with understanding your product’s lifetime costs and requirements. A trade-off needs to occur between the Bill-of-Material (BOM) costs and the software maintenance costs for the product. For example, embedded systems that use Linux find it easier to leverage open-source software and find developers who can write the system software. However, Linux-based systems have more complex hardware requirements than microcontroller-based systems and may have a higher BOM cost. Microcontroller-based systems may cost less, but there are also fewer developers who can successfully design and maintain these systems.

Designers need to weigh both the hardware and software costs to determine whether it makes sense for their product to use hardware that can run Linux or whether a less expensive and less CPU-intensive solution fits better.

Physical Characteristics to Consider

Speaking of hardware capabilities and requirements, when selecting your embedded operating system, it’s also essential to examine the physical characteristic chosen by the hardware. Physical factors of a microprocessor or microcontroller that should be considered include:

• Peripheral feature set
• CPU clock speed
• The available flash storage
• The available RAM

The physical constraints placed on your system by the hardware may immediately constrain what options are available to you. For example, to run a flavor of embedded Linux usually requires the processor contain a memory management unit (MMU). Unfortunately, microcontrollers don’t have an MMU. Therefore, to run Linux, designers will need to at least have an application processor in the Cortex-A range, not a microcontroller in the Cortex-M family (although things change rapidly, and someone may have microcontrollers with an MMU and reasonable clock rate).

To run a flavor of embedded Linux, the hardware must also have at least 8 GB of storage, 16 GB of RAM, and 8 – 16 MB of internal flash storage. A kernel like Linux also probably needs at least a 500 MHz processor. These are much higher than what is required to run an RTOS, which at a minimum needs four kB of RAM, 64 kB of flash, and a CPU running at 24 MHz.  

Real-time Performance

I know from experience that exploring the real-time performance characteristics between bare metal, RTOS, and Linux-based systems is a hot potato. Engineers who focus on microcontroller-based real-time systems will often tell you that you can’t get actual real-time performance from a Linux system. Linux engineers will tell you that isn’t true; there is the real-time patch, which provides actual real-time behavior. From there, the arguments usually get heated.

No matter what side of the fence you are on, it’s essential to look at the real-time requirements and use them in selecting your operating system. Assess how deterministic the system needs to be and evaluate your operating system based on those needs. I’ve seen flavors of Linux real-time that work great; others that don’t. There isn’t a universally correct answer, just a suitable answer for your application.

Software Library Integration

One of the significant differences between using bare metal, an RTOS, or Linux is the availability and the level of integration of the software libraries available to developers. In the bare-metal space, you’re on your own. You are either writing your software from scratch or integrating third-party libraries yourself. An RTOS, on the other hand, will come with a suite of libraries that are already integrated with the RTOS. For example, one might find circular buffers, memory management tools, file systems, etc. More libraries are available and integrated, but there may still be a need to do some of the work yourself.

When you look at Linux, it feels like developers have a nearly unlimited supply of libraries that are available and already integrated with the system. The most appealing and value-added characteristic of embedded Linux is the availability and integration of software libraries. Developers have an operating system as a whole at their disposal. That’s powerful but also potentially dangerous.  

Don’t Forget About Security

Many designers today are building connected systems that must have a secure solution. The operating system plays a significant role in security solutions. For example, if a vulnerability is found in a standard library used by the Linux kernel, every Linux device until it is patched has the vulnerability. The chances are high that a bare metal or RTOS-based system won’t have that same vulnerability. Specific operating systems are targeted by hackers more than others because of the toolsets available to them to hack those devices. For example, I’ve put embedded systems that use an RTOS directly on the internet without protection, and they went weeks without ever being compromised. I once put a Linux-based system on the internet, and it was hacked and became part of a Chinese botnet within 48 hours. In Linux systems defense, I believe the default password was still set, but it shows that if you don’t take the time to configure your OS correctly, it doesn’t take much to hack it.  

Conclusions

There are a lot of characteristics that developers should consider when selecting their operating system. The first characteristics are more related to costs and the business aspects of building products. However, the more significant attributes like available libraries, security, maintainability, etc., also play an essential role. So which operating system should you use and under which circumstances? In the next article, we will explore that question and provide guidelines on where to use bare metal, an RTOS, and Linux.

---

Jacob Beningo is an embedded software consultant who specializes in real-time, microcontroller-based systems. He actively promotes software best practices through numerous articles, blogs, and webinars on topics from software architecture design, embedded DevOps, and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees including a Masters of Engineering from the University of Michigan.

---

Related Contents:

For more Embedded, subscribe to Embedded’s weekly email newsletter.