Most MCUs do not have operating systems. In the “olden days,” most embedded systems had MCUs that ran a program repeatedly and did not have much if any, human interference. However, the line between MCUs and processors is blurring. MCUs have General Purpose Input/Output (GPIO) which are often attached to one or several sensors as input and devices that get activated based on what you’ve programmed the MCU to do. Yet the price of computing has gone down dramatically while performance has gone up, so many embedded devices have high-performance processors with many, many peripherals and tasks to perform. The more tasks and computing that are involved, the more you need an operating system (OS) to make it all easier to organize and run as a coordinated system.

An operating system’s central role is to manage system resources to meet the demands of the applications that depend upon it. Operating systems have some essential elements such as a process scheduler, tasks, memory management, system: interface, filesystems multitasking, and synchronization, interrupt event handling, timers and clocks, inter-task communication, I/O, and memory management.

A Real-time Operating System (RTOS) is an OS for devices and systems that need to react quickly to a trigger. In the case of a software fail-safe, for instance, an RTOS would pre-empt lower priority processes to take care of the higher-priority task. The LiDAR and video imaging that autonomous vehicles use to drive the car down a highway without straying outside the lines or hitting anything is very compute-intensive. It makes sense that a complex system with life-safety responsibilities might have an RTOS so that a processor can make a quick decision. On the other hand, an OS can be detrimental if it’s not really needed, and yet necessary if the system has a processor that must be interrupted so it can react to high priority tasks. Traditional MCUs are not going to run several threads simultaneously and are not going to have sophisticated interrupt capabilities. A while ago, the embedded world was mostly populated by MCUs due to the high price of performance computing and the fact that simple control loops were all that was needed.

Today, the embedded world includes every level from single loop controllers to extremely fast, process-laden, and profoundly inter-connected processor systems that must be relied upon to act quickly every time. Software fail-safes are prevalent; Programmable Logic Controllers (PLCs) are chock full of them in a manufacturing plant. Hardware fail-safes are still a good idea for hazardous processes or systems such as cancer-radiation machines, nuclear plants, and life-safety systems.

When do you need an RTOS?

An RTOS is necessary when there are several processes and devices, and the processes’ timing is more important than average performance. If you need multiple processes to run on a schedule, you need an RTOS. An RTOS can guarantee the timing requirements for processes under its control, has low latency, is predictable in that it can determine a task’s completion time with certainty, and enables the coexistence of both time-critical and non-time critical tasks.

An RTOS can effectively handle interrupts based on priority to control scheduling. Unlike a general-purpose OS, an RTOS is expected to meet computational deadlines, regardless of how bad the scenario can get for the RTOS.

Some of the characteristics of an RTOS are that it must be multithreaded, preemptive, and provide for thread priority. An RTOS must also include a system of priority inheritance, predictably sustain thread synchronization, and have a mechanism to avoid priority inversion. Priority inversion is a situation where a low priority thread uses a resource and delays the execution of a high priority thread when both are competing for the same resources. Additionally, one of the primary provisions of an RTOS is that interrupt latency is predictable.

RTOS developers must have detailed information about the system interrupt levels, system calls, and timing. Developers need to know the maximum time during which the OS and device drivers mask interrupts. The interrupt latency, which is the time from when an interrupt first occurs to when the interrupt task runs, must be predictable and consistent with application requirements.

Some examples of RTOSes are VxWorks, QNX, Win CE, pSOS, Nucleus® RTOS, and FreeRTOS™, the Zephyr™ Project.

What to consider when choosing an RTOS

• What are the real-time capabilities? Is it soft or hard real-time interrupt handling and what are the preemptive scheduling services?
• What is the target processor, and does it support the RTOS you have in mind? Has anyone ported the RTOS to your processor yet?
• How large is the RTOS? IoT devices need small memory footprints, such as that of Zephyr and perhaps FreeRTOS. How you configure the RTOS will also affect its size since the memory footprint is established according to the services that get used by the application.
• What are the RTOS’ interrupt latencies?
• How long does it take the RTOS to switch contexts? (A context switch delay is the amount of time it takes to store the state of a process (or thread) and then restore it and resume execution from the same point later. In this way, multiple processes can share a single CPU.)
• What interfaces does your application need and can they run with the RTOS?
• Does your processor development board have a board support package with your RTOS? (The board support package would include drivers for the peripherals that the application needs.)
• Which development environments and debugging tools work with the RTOS?
• How much does the RTOS cost, is it open source or royalty-free? If open source, what is the license that governs the RTOS and is the kernel stable?
• Does the RTOS have good documentation and/or forums?
• What is the RTOS supplier’s reputation?
• Can a competing company purchase the RTOS (and then refuse to support it)?
• How flexible is the choice of scheduling algorithms in the RTOS? E.g., FIFO, round Robin, rate-monotonic, sporadic, etc.
• Are there tools for remote diagnostics?
• Do you need hard real-time, or will soft real-time do?

Soft, firm, or hard RTOS?

Hard real-time guarantees tasks will be performed within set deadlines. Hard real-time is typically required when loss of life is a possibility if processing deadlines are not met. An example of hard real time is a nuclear plant shutdown system or flight control system.  A soft real-time system is more forgiving; deadlines are important, but only in an average sense. An example of a soft real-time system is a data acquisition system.  A firm real-time system is in between the two above. Firm real-time is mostly soft real-time, but might have a few hard deadlines, as well. Firm real time does not benefit from late delivery of a service. Note that hard versus soft real-time does not necessarily relate to the length of time available.