Most embedded systems are “employed” to perform a task within a specified time. Such “employees” are called real-time systems. The employment chain continues as the real-time systems also “hire” real-time operating systems (RTOS) to meet the job deadlines. Choosing the right RTOS can be a confusing task since there are so many options to pick from. This article compares, from head to toe, the most popular Open-source RTOSes available so that you won’t have to.
What is a Real-Time Operating System (RTOS)?
A real-time OS is a particular type of operating system that manages an embedded system’s hardware to perform the user applications within the specified timing constraints. It differs from the generic OS as it is specifically designed for scheduling processes and managing the system’s limited resources to achieve fast real-time responses. “RTOS, thou art be a great manager.”
In actual fact, any job that a user requests an embedded system to do consists of multiple individual smaller tasks, and execution is switched amongst them quickly enough to give an illusion that a single job is done. However, the CPU “brain” of an embedded system can only focus on one task at a time. How does it choose which task to perform, how much CPU time should a task be allocated, and how does it determine how to switch from one task to the next? How? How? How? Well, this is where the RTOS comes in. As the name suggests, it has a scheduler that provides a schedule as to which task should be executed by examining the priority assigned to each task by the system designer. It also determines how the CPU will switch from one task to another. All of this makes embedded systems with an RTOS have a deterministic execution behavior towards user applications.
Open-source RTOS Comparison (FreeRTOS vs RT-Linux vs VxWorks vs eCos)
This section compares the four most popular open-source RTOSes in Scheduling, Inter-process communication, memory management, and interrupt latency.
FreeRTOS
It is a free, simple, and portable RTOS that Richard Barry created in 2003. It is a minimalistic RTOS, so it can be used in small real-time embedded systems where most RTOSes wouldn’t fit. The FreeRTOS Kernel and Libraries are distributed freely under the MIT OpenSource Licence. The free distribution ensures that this RTOS is freely available to everyone. Its users can retain ownership of their intellectual properties, and it can be used for commercial applications without paying royalty fees.
RT-Linux
Originally, it was developed by Victor Yodaikin and others at the New Mexico Institute of Technology. It stands for real-time Linux and its primary design objective is to give a hard real-time performance in Linux. Simply put, it is a real-time extension to the standard Linux system allowing it to run in two modes. The normal mode to execute non-real-time tasks and the real-time mode to execute real-time tasks. RT-Linux runs on two kernels, the RTCore kernel to execute tasks with real-time constraints (real-time mode) and the regular Linux kernel to execute non-real-time tasks (normal mode).
VxWorks
This is an RTOS from Wind River. Its most famous application is in the NASA rover robots, Spirit and Opportunity. It has been certified by various agencies and international standards like IEC 615088 and ISO 26262 for security and reliability in critical applications.
eCos
Embedded Configurable Operating System. It is a highly configurable, free, open-source RTOS targeted for embedded systems. It has a GUI called eCos configuration tool used to precisely customize the kernel to the specific application, meaning you get to choose functionalities that should be active at runtime. This configurability allows the system’s hardware resources to be optimally used as unnecessary functionalities can be eliminated at runtime to reduce the resource footprint of the RTOS.
Comparison based on Scheduling
FreeRTOS – It uses a Round-Robin, highest priority first scheduler. Meaning tasks with the highest priority are most favored and executed first. Tasks with the same priority are allocated the same CPU time based on a round-robin fashion. All its scheduling algorithms have low overheads.
RT-Linux– It provides many types of schedulers that the developer can choose from. It has the highest priority-driven scheduler, where tasks are given priority by the designer and the task with the highest priority is run first. It also has an Earliest Deadline First (EDF) scheduler. This is a dynamic type of scheduler that ignores the priority of the designer’s task and assigns priority to the task based on a deadline. The most immediate deadline tasks are given the highest priority and run first to avoid any deadline misses.
VxWorks –It uses a priority-based pre-emptive round-robin scheduling algorithm. All tasks have a priority level between 0 and 255, with 0 being the highest priority and 255 the lowest priority. For example, if a task with priority level 2 is currently running and a task with priority level 1 (1 has higher priority than 2) is called, then the current task will be suspended, and execution switches to the called task. This is called task pre-emption. You might wonder about what happens in instances where tasks have the same priority level. In such cases, round-robin scheduling is used.
eCos- It allows the developer to assign priority levels to tasks from 0 to any upper limit of their choice, a typical option being 31. 0 indicates the highest priority. Scheduling is done with two types of schedulers, but only one of them is active at a time. The first is the Bitmap scheduler. It allows only one task per priority level, meaning there will not be any two tasks sharing the same priority level to each their own. Bitmap scheduling is simple, and it has low CPU overhead, but it puts a low limit on the number of tasks/processes that can be run at a time. The second scheduler is the multi-level queue (MLQ) scheduler. Unlike Bitmap, it allows tasks to share the same priority level. Sharing is, after all, caring. With the MLQ scheduler, more processes can be run at a time.
Comparison based on Inter-process communication
Inter-process communication (IPC) is a form of data sharing between processes that happen with RTOS. All the four RTOSes discussed to offer the following message passing techniques: shared memory, pipes, queues, mailbox, signals, and remote procedure calls. The system designer can choose which method to opt for depending on the bandwidth requirements, network transparency, latency, etc.
Comparison based on Memory management
FreeRTOS– Every task that is created in FreeRTOS has a section of heap memory allocated to it. The memory can be dynamically allocated using several ways that differ in complexity.
RT-Linux – A significant drawback in RT-Linux memory management is that it does not support memory protection and dynamic memory allocation. Without memory-protection schemes, the system is less secure, and failure from the application or device driver can put the entire system to a halt. RT-Linux uses a real-addressing technique, meaning the physical address and the logical address of a task are the same. There is no need for virtual memory and memory address translations, and this makes the system faster.
VxWorks– unlike RT-Linux, it supports virtual memory and memory protection schemes. The physical and the logical address of the task are not the same, so address translation is done through the page tables of virtual memory, and even though this is not as fast real-addressing, it does save the system designer/programmer from having to know the physical address allocated to tasks.
eCos– It supports both static and dynamic memory allocation. Static memory allocation gives the system designer more control over the memory resource, while dynamic allocation is more flexible. eCos implements dynamic memory allocation through fixed and variable-sized memory pools.
Comparison based on Interrupt latency
FreeRTOS offers various methods to handle interrupts that differ in both latency and the consumption of resources. These methods include, Standard ISR processing, Application Controlled Deferred Interrupt Handling, and Centralised Deferred Interrupt Handling.
RT-Linux – The regular Linux kernel is modified to be pre-emptive to co-exist with the real-time kernel in RT-Linux. This was done because the standard Linux has a long computation latency for real-time tasks. The regular Linux kernel is marked as a low-priority task in the core kernel, and it is only allowed to run when there are no real-time tasks to execute. All interrupts are first received and analyzed by the RTCore kernel, and if the interrupt is for the regular Linux kernel, it is queued. Only when there are no real-time tasks can the typical Linux kernel read the queue and handle the interrupt. RT-Linux is designed to prioritize real-time tasks and handle them with minimum latency without any distractions from non-real-time tasks in the regular Linux Kernel.
VxWorks – A system with a low interrupt latency is quickly notified by an interrupt and handles it quickly. VxWorks lowers its interrupt latency by a deferral mechanism of handling interrupts. When an interrupt of a higher priority than the currently running task occurs, the task is pre-empted and stored in a work queue, and the Interrupt Service Routine (ISR) is run. All interrupts in VxWorks use the same interrupt stack and run separately and not in the regular task context. This eliminates context switching while handling interrupts and thus reduces interrupt latency.
eCos- The core part of the eCos architecture is the Hardware Abstraction Layer (HAL). It houses the eCos kernel, libraries, and run-time components. The HAL gets ported to the target processor to abstract/ hide the hardware details of the target processor and enable eCos to run smoothly. The HAL supports Interrupt Service Routine (ISR) and Deferred Service Routine (DSR) to enable the user to prioritize interrupts according to system needs. Both the interrupts are re-enabled to maintain low interrupt latency, but how low the latency depends entirely on the configuration options selected by the user (remember the eCos kernel is configurable, the system designer chooses the make-up of the kernel).
Summary
In this section, we laid down the popular free RTOSes and compared their technical attributes. In part two of this article, we will cover commercial RTOSes. See you then!