Embedded RTOS - our experience
March 25, 2024

When starting application development in an embedded system, a developer is faced with the choice of where to start - bare metal or GPOS (General Purpose Operating System, such as Linux), or perhaps RTOS (Real Time Operating System).
What are the differences between the two?

Bare metal.
‍Once
a necessity (who programmed microcontrollers in the first decade of this century?). Today seen by us in unique solutions:
+ very small, specialized mcu;
+ monothematic device functionality;

‍Linux.
‍Gives full hardware support and isolation from the hardware layer. Just application heaven above. The cost of such convenience? You need a relatively large amount of computing power and memory to put up an efficient system. Technological development is slowly obliterating this argument. That leaves the second - either you are strong in Linux and know where what and why, or you are at the mercy of fate. When it works, it's cool and easy. When it doesn't work, sometimes getting to the "why" can take days or even weeks.

‍RTOS.
‍Intermediate solution
. Burdened with additional memory and performance overhead, acceptable in today's microcontroller world (where memory size is at least expressed in tens or hundreds of kB). From simple Round Robin schedulers to mini operating systems (such as Zephyr). We distinguish between soft RTOS and hard RTOS. How do they differ? Hard RTOS have to respond to events within a strict time limit. Soft RTOS "try" to respond to events as soon as possible, by putting such a task into a "to do" queue.

RTOSes are growing in popularity, resulting in their development in the last decade (mainly soft RTOSes).

Their popularity is related to several factors:

  • Microcontroller Development: With the increasing amount of memory available in microcontrollers, we no longer have to worry about how much space the RTOS takes up (within reason, of course).
  • Resource Management: RTOSes often provide their own memory and resource management mechanisms, which makes things easier and more secure.
  • Open Source: Many available RTOSes are offered as open source software, meaning they are free and their source code can be customized.
  • Timing Determinism: The guarantee that the system will always respond to external events at a specific time is crucial for many applications.
  • ‍Modularity: Some RTOSes are highly modular and allow you to customize them to your needs, such as Zephyr allows you to unplug even the scheduler.

According to wikipedia, there are as many as 18 RTOSes available on the market that are compatible with the ARM Cortex-M.
In reality, there are probably many more (we ourselves once committed a small simple RTOSik for tiny 16-biters).

Our professional experience centers around 4 of them. And they are what this series of articles will be about.
And they are:

  • FreeRTOS - owned by Amazon (created by Richard Barry). A simple RTOS with low hardware requirements. A quasi standard RTOS on the market. Made available under an MIT license.
  • Zephyr - an open source project managed by the Linux Foundation. Rapidly developing in the last 2-3 years. Highly modular, support for a large hardware base. Made available under the Apache 2.0 license.
  • ThreadX - a Microsoft-acquired (originally Express Logic) mature system (Microsoft says it is supported by 12 billion devices). Made available under an MIT license.‍
  • embOS - owned by SEGGER. Compatible with MISRA-C 2012 Certified under medical and automotive standards. Commercial license.

The eternal question - which one will be best for our project?
The answer from an experienced programmer can only be one - it depends.

Our conclusion is a bit of a different yardstick - in 70-80% of projects it doesn't matter much.
But what about the other 20-30%?

For as long as we can remember RTOSes have been beating each other for the primacy of feather-light and "zero cycle waste." These days, such a battle is often pointless. In our opinion, what matters most strongly is middleware and community support. And these aspects we will look at most strongly in this series.

What about the practical side? How does their performance compare?

We will check this with 3 simple tests:

  • measuring how long it takes each RTOS to switch contexts between simple shuffles;
  • The periodicity of the shuffles themselves;
  • Check how long it takes to switch contexts when exiting interrupt handling;

In the end, we will compare ourselves the results of performance in a simple, yet practical application that supports the TFT display and calculates the Fourier transform.

#RTOS #Zephyr #FreeRTOS #ThreadX #embOS #GoodByte