We often say RTOS (Real Time Operating System), so what exactly is a real-time operating system? Is it really real-time?

RTOS:Real Time Operating System, which means real-time operating system.

The explanation from Baidu Encyclopedia:

The focus of a real-time operating system is on real-time (timely response). In simple terms, it means that the program can promptly address and handle urgent matters without causing issues like system freezes.

For example: A moving vehicle detects an obstacle ahead with its sensors and must immediately slow down or stop, rather than taking a long time to respond (slow response could lead to a collision).

Comparison with Bare Metal

Students transitioning from bare metal to RTOS often compare the two:

• What advantages does RTOS have over bare metal?

• Is RTOS more convenient than bare metal?

• ……

I can confidently say: RTOS is indeed more convenient and has more advantages compared to bare metal. Of course, this is under the condition that the MCU resources (Flash, RAM) meet the demands.

In the early days, MCU resources were relatively scarce; for example, Flash was below 10K, and RAM was below 1K. In such cases, the advantages of using RTOS were not obvious and could even expose its shortcomings.

However, now MCUs have relatively abundant resources, often exceeding 1M Flash and 100K RAM. In this scenario, running bare metal feels like a waste of MCU resources.

Comparison with Time-Sharing Operating Systems

Many people might think of time-sharing operating systems (TSOS) and wonder what the differences are between RTOS and TSOS, and what characteristics each has.

Modern processors are faster, and time-sharing operating systems have high real-time capabilities as well. The differences can be understood from the literal meaning: time-sharing is divided into time slices, which are very small, usually at the microsecond level or even lower.

Understanding the scheduling mechanism of TSOS will help clarify the differences between the two. You can refer to my previous article:What are the differences between RTOS and TSOS?

Returning to today’s topic: Is RTOS really real-time?

Strictly speaking, RTOS does not respond and handle urgent matters in real-time, it just responds in a very short time (usually at the millisecond level), giving the impression of real-time response.

A single CPU can only handle one task at a time (it can only execute one program at a time). When you create multiple tasks (task 1, task 2, task 3, etc.), the CPU executes them in turn (according to priority).

1. System Tick

RTOS real-time response has an important configuration, which is the system tick (SysTick).

For example, in FreeRTOSConfig.h

#define configTICK_RATE_HZ        ((TickType_t)1000)

Another example is in μCOS system’s os_cfg.h

#define OS_TICKS_PER_SEC        1000u

The system tick determines the time size of the RTOS underlying scheduling. If set to 1000, it means a response will be made every 1ms.

Taking the earlier example of the vehicle encountering an obstacle: when the sensor detects an obstacle, it notifies a higher-priority task to brake, and this process requires a response in just 1ms.

You might say: If I set it to 10000, will it respond in 0.1ms? Is a larger system tick always better?

Theoretically, a larger system tick value results in faster responses, but system scheduling also requires time:

The length of the scheduling time remains constant. If the time between N and N+1 is shorter (tick), the time left for executing tasks becomes shorter.

Therefore, the tick value is not always better when larger; a reasonable value is needed. You can refer to:What is the appropriate tick setting for real-time operating systems?

2. Hardware Interrupts

Students transitioning from bare metal development to RTOS often think: I can achieve real-time response using interrupts.

Indeed, interrupts can achieve real-time response, but they cannot meet most needs.

For instance, in the previous example of the vehicle braking: if an obstacle is detected and an interrupt response is immediately executed to slow down, if this action is an S-curve (deceleration), taking 1 second to execute.

If you execute this 1-second braking action within the interrupt function, the CPU will not be able to perform any other tasks. Would that be acceptable?

Hardware interrupts can only provide an “emergency notification”; they cannot execute (time-consuming) actions.

RTOS, combined with hardware interrupts, perfectly solves this issue. The interrupt notifies a high-priority task to execute the braking action, which may take 1ms.

Thus, you will find that RTOS is not truly real-time; it is just that the time is so short that you don’t notice it.