Is RTOS Really a Real-Time Operating System?

Follow+Star public number, don’t miss wonderful content

Author | strongerHuang

WeChat public account | strongerHuang

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

The explanation from Baidu Encyclopedia is as follows:

The key point of a real-time operating system is real-time (timely response). In simple terms, it means that the program can promptly address and handle urgent matters without experiencing situations like “lagging”.

For example: A moving car detects an obstacle ahead with a sensor and must immediately slow down or stop, rather than taking a long time to react (if the reaction is slow, it will crash into it).

Compared to bare metal

Students transitioning from bare metal to RTOS often compare bare metal with RTOS:

• What are the advantages of RTOS compared to bare metal?

• Is RTOS more convenient than bare metal?

• ……

I can confidently say: RTOS is indeed more convenient and has more advantages than bare metal. Of course, this is assuming that the MCU resources (Flash, RAM) can meet the requirements.

Because early MCUs had relatively scarce resources, such as Flash under 10K and RAM under 1K, using RTOS at that time did not show obvious advantages, but rather exposed more disadvantages.

However, now that MCU resources are relatively abundant, often exceeding 1M of Flash and 100K of RAM, if running bare metal, I feel it is a waste of MCU resources.

Here, I recommend reading:

Compared to time-sharing operating systems

Many people will think of time-sharing operating systems (TSOS). What are the differences between RTOS and TSOS? What are their respective characteristics?

Now that processors are relatively faster, the real-time capability of time-sharing operating systems is also high. Their differences can actually be understood from their literal meanings; time-sharing means divided into time slices, and this time slice is very small, generally at the microsecond level or even lower.

If you understand the scheduling mechanism of TSOS time-sharing operating systems, you will better understand the differences between the two.

This section can refer to my previous shared article:What are the differences between RTOS and TSOS?

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

Strictly speaking, RTOS does not respond and process urgent matters in real-time, but only responds in a very short time (generally at the millisecond level) and gives 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 tasks 1, 2, 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)

And in μCOS system os_cfg.h

#define OS_TICKS_PER_SEC        1000u

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

Taking the example of the car encountering an obstacle: when the sensor detects an obstacle, it notifies a higher priority task to brake, and this process will respond in just 1ms.

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

In theory, a larger system tick value means a faster response, but scheduling also takes time:

The length of scheduling time remains unchanged. 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, which can be referenced in:How to Set the Tick for Real-Time Operating Systems?

2. Hardware Interrupts

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

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

Taking the example of the car braking: if an obstacle is detected ahead and an interrupt response is immediately made to execute a deceleration action, if this action is an S-curve (deceleration), the execution time is 1s.

If you perform this 1s braking action inside the interrupt function, the CPU will not be able to do anything else. Do you think that is acceptable?

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

RTOS combined with hardware interrupts can perfectly solve this problem: the interrupt notifies a high-priority task to execute the braking action, but this process may take 1ms.

Therefore, you will find that RTOS is not truly real-time; it simply responds in a very short time that you cannot perceive.

———— END ————

● Column “Embedded Tools”

● Column “Embedded Development”

● Column “Keil Tutorials”

● Selected Tutorials from the Embedded Column

Click “Read Original” for more shares.