New RTOS embOS-Ultra
Real-Time Operating System – Saving Energy Without a System Tick
Almost 40 years after the introduction of the first RTOS for embedded systems, Segger Microcontroller presents embOS-Ultra, a completely new approach in scheduling. The advantages compared to conventional RTOS include higher precision and more energy-efficient operation - effectively by default.
In the embedded world, where demand for »hard« real-time applications is the rule rather than the exception, the use of a real-time operating system (RTOS) has become more and more common. The reason for this is simple: Studies in software engineering in the 80s showed that the highest increase in productivity in software development is achieved through reuse.
Before discussing the specific innovations and advantages of embOS-Ultra compared to all conventional RTOSes known so far, the use of an RTOS in the embedded world shall be discussed in general for a better understanding.
Even in a comparatively simple application like the control of a washing machine, temperatures and pressures have to be measured and motors and pumps have to be controlled. One implementation without RTOS is the so-called super-loop architecture – also known as »bare-metal programming«. Here, there is no operating system, and the structure is quite simple: In the main() function, one sets up all variables, drivers, libraries, etc., and then executes one or more periodic tasks in a while loop (Figure 1).
External events must be programmed at the interrupt level of the processor, which communicates with functions from the main loop via global variables. There are always dependencies between data, time, functions and priorities. A large problem occurs, if program parts from the main loop are extended, then the time behavior of the whole application changes. It is also difficult to process a program in a priority-oriented way with this approach.
Disturbances in one function means all others are also affected, making the system very error-prone. Further disadvantages are the loss of computing time by polling and missing multitasking, since an intervention into the program sequence is possible only by interrupts.
Of course, there are other challenges such as the manual management of resources, e.g. timers, interfaces, memory and computing time, which all have to be shared.
Advantages of Using an RTOS
The use of an RTOS eliminates the described disadvantages, since the operating system takes care of all these tasks, such as resource management. The application is divided up by the programmer into so-called threads, whereby a high degree of modularity is achieved. Tasks that are to run with different priorities are implemented as separate threads (Figure 2).
Each thread has a specific state at any point in time. The three basic states are:
- Running: the thread is executing. On a single-core microcontroller, of course, only one thread can be in the Running state at any given time, since there is only one CPU available.
- Ready: The tasks in the Ready state are ready to run and are waiting for the CPU to allocate them.
- Waiting: The tasks are not ready to run at the moment. Only once certain events have occurred, e.g. data is available or a certain time has been reached, do the threads become Ready.
The central switching point of the RTOS is the scheduler. It determines which thread gets the CPU allocated. All threads must be executed before their deadline to avoid problems. The deadline is the maximum permissible time, which may pass from the arrival of an event to the completion of the associated function, without causing issues.
Threads can be executed virtually concurrently, even if the embedded system on which they run has only a single CPU. This is done in one of two ways: time-slicing or priority-driven scheduling. Most RTOSes, such as Segger's embOS, allow both types of scheduling to be combined.
Time-Slice Driven and Priority Driven Scheduling
In a time-slice system, also known as a »round-robin« scheduling system, all threads that are ready to execute are executed for a specified time, the time slice. Then, the next thread is executed for a specified amount of time – usually the same amount. In this way, all threads share the CPU equally. A time slice is usually one ms or a multiple of one ms.
The disadvantage of the time-slice approach is that the execution of a given task can take several time slices, i.e., a few ms or even dozens of ms. This is not critical for things like the user interface (UI). The user will not notice a delay of, say, 10 ms in response. However, for a network stack that can operate in a separate thread, this can be critical. If the network stack takes that much time to respond, it may not be able to complete its task.
The solution to this is priority-driven scheduling, where more time-critical tasks have a higher priority than less time-critical tasks. In this example, the UI task would have a lower priority than the network task. The network task can wait for an event in this way. The event can be triggered by an ethernet interrupt when a data packet is received. This allows the RTOS to immediately activate the network task, which can then immediately process and respond to the incoming packet.
Another advantage of using an RTOS that should not be underestimated is hardware abstraction: Especially now in the chip crisis, for example, the importance of portability of applications from one hardware platform to another has become apparent. Whereas with in-house developments you are locked into a specific controller regardless of the higher development and maintenance effort, Segger's embOS, for example, supports almost 1,000 different microcontrollers, making it very easy to switch without having to change the application. How this looks in practice has been described by a well-known industrial company in electronics [1].
- Real-Time Operating System – Saving Energy Without a System Tick
- The RTOS Revolution: Cycle-Resolution-Scheduling of embOS-Ultra
