RTOS, part 1

A RTOS (Real-Time Operating System) library consist of several components that most often are compiled or linked into embedded applications as a library. You don’t really need a RTOS in embedded systems as many are happy running things in a loop (also called Round Robin) and timing things themselves. However, as applications get more complex you end up doing more and more of what I would expect from a RTOS library in your code and at the end it can end up a bit messy. I have a strong preference for using a RTOS and I have a library that I have been using for decades. I ported this to Arduino earlier to run 20+ tasks on a 2Kb SRAM computer.

rtos2

The illustration above show some of the main components in a RTOS package. A bootloader, a kernel, a HAL library, a Watchdog system and CLI (Command Line Interface) is usually included in many packages.

The RTOS I will use is called yX (myx) which stands for micro kernel. The core of yX is as with any other RTOS a kernel that will change from task to task under timed control. yX is however very special in the sense that it is a “linear scheduler” that combines options for actual threading schemes with round robin schemes and offer a very high scalability.

 A linear scheduler focus on continuous usage of resources with minimum of interruptions. One part of this is that we avoid thread shifting and run tasks in sequence (an advanced form of round robin). The second part is that once we thread shift we allow multiple tasks to use the same stack either by using the main stack or by sharing a 2nd stack.

 The result is scalability without compromising CPU load or memory usage. The effect is so good that yX is also used to extend the capabilities of Windows and Linux applications. The later even allow embedded tasks to be moved and run on a host computer, something we will return back to later.

 An embedded Real-Time system have main three concerns:

  • Timing of hard real-time tasks
  • CPU usage
  • Memory usage

Timing requirements are often so hard that they can only be achieved by hardware, an hardware timer or running the task very tight in the main loop. yX can support this directly, but maybe more important is that it can adapt to let the application take over and only focus on support tasks.

One important reason why you actually need a proper RTOS is re-usability of code. The RTSO library with it’s HAL is often the required code needed as infrastructure to make module portable in the first place.

Leave a Reply