While real-time operating system (RTOS) software is becoming a key feature in the out-of-box support for embedded systems built around MCUs, the overall concept of RTOS is still muddy for many design engineers.
So, here is the when and why RTOS solutions are needed in embedded designs. But, before that, what is RTOS anyway, especially when compared to bare metal solutions?
What
An RTOS is an operating system designed to manage hardware resources of an embedded system; it creates multiple threads of software execution and a scheduler for managing these threads. Another way to put it is a scheduling kernel that creates a multi-tasking and deterministic run-time environment.
Figure 1: A comparison between non-RTOS and RTOS executions. Image: Texas Instruments
The presence of a scheduler and the capability of assigning precise and reproducible time slots for the running tasks distinguishes RTOS solutions from embedded designs based on “bare metal” programming. That brings us to when embedded developers should make a switch from the bare-metal system to RTOS.
When
An RTOS is commonly used when there are more interrupt sources, more functions, and more communication interfaces. In short, it’s the application complexity that mostly decides the use of RTOS tailored for MCUs.
Another way to determine whether an RTOS is needed is to watch out one of the following design requirements: 1) TCP/IP or other complex networking stacks, 2) a complex GUI, or 3) a file system. Here, it’s worth mentioning that a design encompassing all three requirements will merit the use of a full-fledged operating system.
Figure 2: The block diagram of an embedded system design incorporating an RTOS. Image: GitHub
What an RTOS does here is suspend a task while giving higher priority to tasks with real-time requirements. Here, RTOS software, a collection of initialization routines, drivers, and utility functions, provides inter-thread synchronization mechanisms and software timer services.
How
Once an embedded developer decides to use an RTOS solution, the first thing to see is the amount of RAM and flash available in a microcontroller. An RTOS solution may require 6 KB to 10 KB of flash, so as a rule of thumb, the MCU should have around 32 KB of flash memory to ensure that there is ample space for the application code.
Likewise, 4 KB to 8 KB of RAM is advisable for supporting RTOS operations, given that each task has its own control block and stack. Many 32-bit MCUs set 2 KB of RAM per task or stack by default.
RTOS in the IoT era
The Internet of Things (IoT) bandwagon is accelerating the use of third-party software stacks, especially the TCP/IP and USB stacks that few developers want to write. And these third-party stacks and tools are often compatible with various RTOS solutions.
Moreover, popular RTOS solutions like Azure RTOS, Amazon FreeRTOS, and Segger’s embOS are being qualified for MCUs from large suppliers. This out-of-box integration is crucial in managing software complexity and lowering the barriers to entry for smaller embedded design outfits.
However, the use of RTOS also increases the overall system complexity and may introduce new types of bugs. So, developers must have adequate knowledge of how to implement RTOS-based programs effectively.
That’s pretty nice! I’m still working with round robin sketch using time periods comparisons.