Embedded systems are microcontroller-based systems that are designed to perform specific functions such as reading sensor data, responding to external events, communicating with other systems, controlling processes, etc. The tricky part is to make the distinction of what exactly qualifies such a system as real-time. Aren’t all embedded systems operating in real-time? In order for an embedded system to be classified as real-time, it must guarantee a strictly defined response time to the events it is tasked with observing and controlling. It should be noted that all systems have a response time (latency). Real-time embedded systems do not react immediately to every event but can guarantee a worse case response time.

Real-time operating systems (RTOS) provide a framework that enables guaranteed response times and deterministic behavior. This is achieved using a scheduling mechanism. This mechanism is at the heart of every RTOS. We can design a real-time embedded system without the use of RTOS, however, using one can make the design process shorter and the whole system easier to manage.

As part of the embedded system abstraction layers, an RTOS is placed above the low-level device drives and below the user application. The RTOS does not provide low-level drivers for microcontroller peripherals. Some RTOS may contain middleware software such as networking, file systems, etc.

Abstraction layers of an embedded system software
Fig. 1 RTOS within the embedded system abstraction layers

RTOS Main Components


A piece of code performing a specific function is usually called a task. A task can be also referred to as a thread, process, activity, etc. in different operating systems.

An operating system is expected to execute many different tasks at once – reading inputs, outputting data, reacting to events, etc. A single microprocessor, however, can execute code from only one task at a time. Achieving the required multitasking is possible using a mechanism known as time multiplexing. Each task that the operating system should execute is given a time window in which it can utilize the CPU, and then the execution of another task proceeds according to a predefined scheduling algorithm. If the timing requirements of all the tasks are fulfilled we can say we have concurrent like executions of multiple tasks without the use of separate microprocessors for each task.

An RTOS task usually has the following main states:

  • Running State – The task’s code is currently being executed by the CPU.
  • Ready State – The task is ready to be put into the running state. In the ready state, the task does not consume any CPU cycles.
  • Blocked State– The task is in this state when it waits for the occurrence of some event. In this state, the task does not consume any CPU cycles.

Some RTOS implementations may contain additional task states or have a different naming convention than the ones listed above, but they are all following the same logic.

Typical states of an RTOS, Ready state transition to running state and vice versa.
Fig. 2 RTOS task states with preemptive scheduling


The scheduler is an integral part of every RTOS. It controls which task should be executed at any given point in time. The scheduler may use various types of algorithms for performing the scheduling of the tasks. Almost all of these algorithms can be classified into two main types:

  • Preemptive Scheduling – this algorithm allows the interruption of a currently running task, so another one with higher priority can be run.
  • Non-preemptive Scheduling (a.k.a Co-operative Scheduling) once a task is started it can’t be interrupted, it will run until it decides that it should release the CPU to another task.


Having introduced what an RTOS is, we should make it clear that it is not a solution for all types of embedded systems. The so-called bare-metal applications are still a viable solution for many real-time systems. The real power of an RTOS can be harnessed in complex embedded systems. Some of the most common advantages and disadvantages of using an RTOS are listed below.


  • Better Structure and Scalability – Using an RTOS gives you a well-defined mechanism for adding and removing software modules.
  • Timing Constraints -Using RTOS makes it easier to fulfill the timing requirements of the many modules used in complex embedded systems.
  • Better Focus – RTOS allows you to focus on the actual application by offloading the development of components such as memory management, exception handling, power management, etc.
  • Functional Safety – There are RTOS distributions that are pre-certified for standards such as IEC 61508 and ISO 26262. This can greatly reduce the development effort in systems that must comply with such standards.


  • Learning Curve – Even the simpler real-time operating systems will require time for learning their specifics and how to properly use them.
  • Price and Licensing – Although there are many free RTOS, their licenses may differ a lot. If you want to use a free RTOS for commercial products there may be some limitations or fees.

Popular real-time operating systems are FreeRTOS, mBed, TinyOS, Riot, Zephyr, etc.

Was this article helpful?