Is Embedded Real-Time Operating System Truly Real-Time?

We often say RTOS (Real Time Operating System) real-time operating system, but what exactly is a real-time operating system? Is it truly real-time?I believe many beginners have this question.

Brief Introduction to RTOS

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

According to Baidu Baike’s explanation:

A real-time operating system is one that can accept external events or data and process them at a sufficiently fast speed, with the results being able to control the production process or respond quickly to the processing system within a specified time, scheduling all available resources to complete real-time tasks, and controlling all real-time tasks to operate in coordination with each other.

The focus of a real-time operating system is on real-time (timely response). In simple terms, it means that the program can timely solve and handle some urgent matters without experiencing issues like “hang-ups”.

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

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 than bare-metal and has more advantages. Of course, the premise is that the MCU resources (Flash, RAM) can meet the demands.

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

However, now that MCU resources are relatively abundant, often exceeding 1M of Flash and 100K of RAM, running bare-metal in this case seems like a waste of MCU resources.

Recommended reading:

The Shift in Thinking from Bare-Metal to RTOSThe Differences Between Bare-Metal and Multithreading SystemsIs It Meaningful to Run RTOS on 51 Microcontrollers?

Comparison with 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?

Nowadays, processors are relatively faster, and the real-time capability of time-sharing operating systems is also high. The difference can actually be understood from the literal meaning; time-sharing means divided into time slices, which are 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?

Is RTOS Truly Real-Time?

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

Strictly speaking, RTOS is not truly real-time in responding to and processing urgent matters, it only 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 the same 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

A crucial configuration for RTOS real-time response is the system tick (SysTick).

For example, in FreeRTOSConfig.h

#define configTICK_RATE_HZ        ((TickType_t)1000)

And in the μCOS system’s os_cfg.h

#define OS_TICKS_PER_SEC        1000u

The system tick determines the size of the scheduling time at the RTOS level; if set to 1000, it means scheduling occurs every 1ms, indicating a response every 1ms.

Taking the previous example of the car encountering an obstacle: when the sensor detects an obstacle, it informs 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 always better?

Logically, a larger system tick value leads to faster responses, but system scheduling also requires time:

The length of scheduling time remains unchanged; if the time between N and N+1 is shorter (tick), the time available for executing tasks becomes shorter.

Thus, the tick value is not always better when larger; a reasonable value is needed, which can be referenced in:How Much Should the Tick Setting Be for Real-Time Operating Systems?

2. Hardware Interrupts

Students transitioning from bare-metal development to RTOS often have this mindset: 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 example of the car braking: if an obstacle is detected ahead and an interrupt response is immediately made, executing the deceleration action, if this action is an S-curve (deceleration), taking 1 second.

If you execute this 1-second braking action inside the interrupt function, the CPU won’t be able to perform other tasks; do you think that’s acceptable?

Hardware interrupts can only provide an “urgent notification” but cannot perform (time-consuming) execution 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 require 1ms.

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

———— END ————

Friendly Reminder

Due to recent changes in WeChat Official Account’s push rules, if you want to frequently see our articles, you can click “Like” or “View” at the bottom of the page after reading each time, so that the articles pushed will appear at the top of your subscription list.

Friendly Reminder

Related posts

Leave a Comment Cancel reply