Learn how to develop IoT applications more efficiently with RTOS (Real-time operating system). See what the main advantages of using RTOS are, what are the hardware requirements, and how you can use RTOS with Zerynth OS.
Bare-metal vs RTOS based development
In embedded systems programming, there are two types of firmware development methods commonly used: bare metal (super loop) based and RTOS based.
You might be asking yourself, “What are the differences?”
Bare metal is also known as super loop in embedded systems. With this method, there is a single loop, and we write every task code inside this super loop, except interrupts. In bare metal programming, firmware or application code is written using memory-mapped peripheral registers in such a way that firmware can run directly on microcontroller hardware without the need for any abstraction layers such as device drivers or an operating system.
In RTOS based embedded systems, every task is scheduled according to a specific period, and aperiodic/sporadic tasks can also be easily scheduled. In these systems, the OS kernel and device drivers provide an interface between the actual application code and the microcontroller’s hardware.
Different kinds of RTOS available for developers
- Hard Real Time: In Hard RTOS, the deadline is handled very strictly. This means that a given task must start executing at a specified, scheduled time, and must be completed within the assigned time duration. (Medical critical care system, aircraft systems, etc.)
- Firm Real Time: This type of RTOS also needs to follow deadlines. However, missing a deadline may not have a big impact but could cause undesired effects, like a huge reduction in the quality of a product. (Various types of multimedia applications.)
- Soft Real Time: Soft Real time RTOS, accepts some delays from the operating system. In this type of RTOS, there is a deadline assigned for a specific job, but a delay for a small amount of time is acceptable. So, deadlines are handled softly by this type of RTOS. (Online transaction system and livestock price quotation systems for example)
Why use a Real-Time Operating System?
Below are productivity advantages and important reasons to consider using an RTOS:
1. Preemptive multitasking design paradigm
For more complex real-time applications, especially those with a code base that is progressively enhanced with each release, the preemptive multitasking design paradigm is superior.
This design paradigm makes response times to each real-time event relatively independent of each other. As a result, new functions can be added without disrupting existing hard real-time ones.
2. Manage complexity
Your project becomes more manageable if it is decomposed into independent threads or processes while using OS services such as message queues, mutexes, semaphores, and event flags to communicate and synchronize.
3. More efficient use of CPU resources while Managing the power
Because RTOS-based applications are interrupt-driven, it is possible to largely eliminate polling from the application. This frees up processor resources for useful work and enables power-saving modes to be invoked during idle periods.
The power consumption profile is controlled by the periodic exit and then re-enters to the low power state to process tick interrupts. Furthermore, if the frequency of the tick interrupt is too high, the energy and time consumed entering and then exiting a low power state for every tick will outweigh any potential power saving gains.
Some RTOSs have tickless idle mode that stops the periodic tick interrupt during idle periods (periods when there are no application tasks that are able to execute), and then makes a correcting adjustment to the RTOS tick count value when the tick interrupt is restarted.
Stopping the tick interrupt allows the microcontroller to remain in a deep power saving state until either an interrupt occurs, or it is time for the RTOS kernel to transition a task into the Ready state.
Hardware requirements to use RTOS
Often RTOS is used to manage several real-time events to ensure responsiveness. However, not all MCUs are appropriate for using an RTOS. So a review of some of the key capabilities that allow or facilitate hosting an RTOS on a specific MCU is useful to designers of real-time embedded systems.
For example, the most widely used version of RTOS – FreeRTOS requires approximately 300 bytes of RAM and 2KB of flash memory. It depends on the features which are enabled that use the compile pre-processor. More important topics to consider are:
1. Advanced interrupt controllers
As the famous saying goes: Not all interrupts are equal, some are more equal.
Advanced interrupt controllers are needed to assign a different priority to each interrupt, depending on the application, this can be critical in executing the function in a timely manner.
2. Memory footprint
Two of the most common concerns engineers have when switching to an RTOS-based implementation, from a purely interrupt or control-loop design, are memory footprint and low power. Since each RTOS process needs a special control block in SRAM to store various state information for the process, engineers are often concerned that they will run out of SRAM and be “starved” of memory for their application. Luckily, RTOS memory footprints have been constantly improved as context switching times and control-block sizes have been optimized.
RTOS in Zerynth OS
Zerynth uses an underlying layer of FreeRTOS, alongside other layers that enable real-time IoT applications running on Python and C.
This layer enables real-time priority preemptive scheduling of tasks and also does not complicate the code like when using standard FreeRTOS codebase.
For instance, here is a multi-threading example on Zerynth OS:
Users can focus on the program logic, the added value of the application and leave all of the underlying, low-level details to Zerynth OS.
For more information on how Zerynth OS uses RTOS, Please refer to our documentation.