As the ancients said: “Timing, location, and harmony are essential”. Embedded RTOS (Real-Time Operating System) has gained significant attention in recent years.

Embedded MCUs have long surpassed the era of only 8MHz clock speeds; currently, embedded main control chips can reach clock speeds of up to 600MHz, and ordinary MCUs can easily run at 64MHz. Not only has there been a qualitative leap in clock speed, but the Arm Cortex-M series MCUs have also added native core instructions to support RTOS in their initial kernel design.

However, although RTOS is called a “real-time operating system,” is it really real-time? What does real-time refer to? Recently, engineers on the EEWorld forum discussed the topic of RTOS, covering what RTOS can do, what real-time means, the types of RTOS based on real-time characteristics, and their personal understanding of RTOS. (Original post link: https://www.eeworld.com.cn/a0a54CC)

Fu Bin | Editor

Electronic Engineering World (ID: EEworldbbs) | Produced

Understanding Bare Metal, RTOS, and GPOS

To understand the “real-time” of RTOS, one must first understand the three current development forms in the embedded field—bare metal development, RTOS, and GPOS (General-Purpose Operating System). Their main characteristics are as follows:

Bare Metal:Bare metal systems do not use an operating system. Instead, application code runs directly on the hardware without operating system support, allowing for direct interaction with and access to hardware. Bare metal development works very well in resource-constrained scenarios, such as 8-bit or 16-bit MCUs, or when there is only 32KB flash and 2KB RAM. Naturally, bare metal can also be used when resources are abundant, such as in systems with high real-time requirements. Currently, many engineers on the EEWorld forum prefer to develop on bare metal.

RTOS:As the name implies, RTOS is designed to serve real-time applications that provide predictable execution times for time-sensitive applications, characterized by responsiveness and determinism. Compared to bare metal, RTOS is more convenient. To use RTOS, the system should have at least 64KB flash, 4KB RAM, and a processor clock of 80MHz or higher.

RTOS is typically used in systems with more complex timing requirements than bare metal, often needing to manage real-time demands while handling communication stacks like TCP/IP, MQTT, USB, and Wi-Fi. Although bare metal can develop such systems, RTOS can simplify design, speed up time to market, and make software maintenance easier. Another key point of RTOS is the added functionalities in software development, such as task management, task synchronization, scheduling, and inter-task communication. RTOS allows for consideration of mutually preemptive tasks, enabling more complex application designs.

GPOS:Includes systems like Linux and Windows, designed to run various software applications. These operating systems are designed for user interaction, providing some interface, whether command-line interface (CLI) or graphical user interface (GUI), aimed at running multiple applications (often multi-threaded) and offering other advantages such as resource/file management and device drivers. User interaction is typically the main focus in GPOS design, so some latency is acceptable. Additionally, the hardware is usually 32-bit or higher, with clock speeds exceeding 200MHz and flash memory in the megabytes.

Due to the complexity of Linux itself, real-time Linux (such as Ubuntu’s real-time Linux) has been developed, which sits between RTOS and Linux. The core concept of real-time Linux is “preemption,” which interrupts the currently executing thread to immediately handle higher-priority events. The choice between RTOS and real-time Linux depends on specific system latency requirements and the need for overhead and resource efficiency. While real-time Linux provides robust solutions for many scenarios, dedicated RTOS may still be preferable in certain critical embedded systems. If a project needs to balance real-time requirements with the flexibility of running various applications, real-time Linux offers a more general solution.

What RTOS Cannot Do

From bare metal to RTOS, engineers often face many confusions. On the EEWorld forum, engineer jorya_txj shared his past experiences and understanding of RTOS:

He mentioned that he has interacted with several individuals transitioning from bare metal to RTOS and has some insights from various projects. For those unfamiliar with RTOS, it may seem mysterious and capable of solving any issues that bare metal cannot handle, but the reality is often different.

Bare metal is most efficient when doing one thing. If even a single task is difficult for bare metal, RTOS cannot solve hardware debt issues; rather, using RTOS may worsen the situation. For example, if a system has a 20us interrupt frequency on a Cortex-M3, with a maximum interrupt handling time of 10us, then only 10us is left for RTOS after the interrupt. This 10us must also accommodate the API call to send to RTOS’s queue. While some systems can respond to 20us interrupts, they cannot guarantee that the API call and interrupt handling can be completed within 10us. Even if it can be guaranteed, the efficiency of tasks outside will be very poor.

The vast majority of RTOS cannot handle interrupt responses within 1us. This means that once an interrupt occurs, the user interrupt function must be handled within 1us.

The above two examples can only be addressed from a hardware design perspective, fundamentally solving the problem. For instance, the first issue can be approached by using dedicated chips or controllers to reduce interrupt frequency. The second issue can be addressed using FPGA for precise timing, and so on.

RTOS is more like a military management decision-maker rather than a warrior charging ahead. The more complex a system becomes, the greater the advantage of RTOS; the simpler a system is, the less useful RTOS becomes. RTOS is often not a lifesaver; hardware design issues still need to be solved by hardware design, and cannot be hoped to be resolved by software. Even if software can solve the issue once, it may not be able to do so next time, lacking generality.

Engineers’ Questions About Real-Time

On the EEWorld forum, senior engineer Xin Xing once posted a discussion about the question—what exactly is “real-time”.

When someone asked him, “What is real-time?”, he responded, “It’s about being quick; for example, when opening a webpage, ideally, you shouldn’t wait even 1ms…” However, the response was that no one understood what real-time meant. In fact, real-time refers to responding within a specified time, rather than just being as fast as possible.

Based on response times in microseconds, milliseconds, and seconds, the real-time response of systems is divided into three types, with RTOS belonging to hard real-time:

• The first type is hard real-time, which responds to immediate events and must not miss processing deadlines; any missed deadline is considered a system failure. This closely resembles the timely response of RTOS we often discuss. It does not emphasize how fast the response is, but rather that it must be completed within the specified deadline.

• The second type is soft real-time, which allows for frequent missed deadlines as long as tasks are executed in a timely manner, and their results continue to be valuable. This is similar to commonly used systems like Windows and Linux desktop versions, where soft real-time refers to statistical real-time, generally characterized by large overall throughput or fast overall response, but cannot guarantee that specific tasks will be completed within a designated time.

• The third type is firm real-time, where even if the system fails to meet the deadline, it may not be considered a failure, even for multiple requests. However, once the specific request’s deadline has passed, the response to that request (such as query responses or task results) will be worthless (the usefulness of results after the deadline is zero).

Other engineers also have their own understanding of real-time. They believe that real-time means the system’s response time to events can meet demands, thus can be considered real-time, as events can always be processed within the limited time. Specifically, the response time of each event has a definite relationship with real time. In a normal working environment, there will be no uncertainty, and such a system is called a real-time system.

Therefore, it can be said that what is referred to as real-time is not truly real-time. Well-known embedded engineer StrongerHuang has also written: Strictly speaking, RTOS does not respond to and handle urgent matters in real-time; it only responds in a very short time (generally at the ms level), creating the impression of real-time response.

For example, the critical configuration for real-time response in RTOS is the system tick (SysTick). In theory, a larger system tick value leads to faster responses, but system scheduling also consumes time, so a larger tick value is not always better. Similarly, interrupts can achieve real-time response, but hardware interrupts can only provide an “emergency notification” and cannot perform (time-consuming) execution actions.

Moreover, other engineers have shared that the real-time aspect of RTOS refers to controllable timing, capable of completing execution within a certain demand time window. It does not mean immediate execution, hence RTOS is a real-time operating system. After exiting a hardware interrupt, high-priority tasks are executed immediately, so if priority configurations are reasonable, responses can be achieved in us or even ns levels. In fact, well-written bare metal responses are similar to RTOS, but RTOS’s greatest advantage lies in task scheduling, allowing for complex functionalities to be scheduled without worrying about task conflicts.

Four Classifications of RTOS

In fact, RTOS can also be classified into four types based on response levels, used for different types of embedded systems:

1. Hard Real-Time Operating Systems (Hard RTOS): Widely used in embedded solutions that handle critical tasks and require precise timing constraints. This means certain events must be executed at a scheduled time, neither early nor late, as this could lead to severe issues or even physical damage to the system. Examples include automotive cruise control and railway signaling systems.

2. Soft Real-Time Operating Systems (Soft RTOS): Suitable for embedded systems where missing predefined timing constraints does not severely affect related processes and overall system operation. It allows for setting deadlines for executing specific tasks, but missing these deadlines does not halt system operation. Examples include in-flight entertainment and voice chat applications.

3. Firm Real-Time Operating Systems (Firm RTOS): A middle ground between hard RTOS and soft RTOS, operating as follows: When using firm RTOS, system tasks may miss deadlines without affecting processes and system operation. However, the number of tasks that can be missed is limited, and exceeding this limit will lead to severe system errors and delays. Examples include robotic assembly lines and telecom networks.

4. Deterministic Real-Time Operating Systems (Deterministic RTOS): Perfectly matches embedded systems that require precise timing. This type of real-time embedded programming allows for predicting the time required to execute tasks of different priorities and complexities. Deterministic scheduling enables us to set accurate time frames for executing critical tasks, making embedded systems predictable, stable, and reliable.

References

[1]https://bbs.eeworld.com.cn/thread-1300391-1-1.html

[2]https://bbs.eeworld.com.cn/thread-473427-1-1.html

[3]https://bbs.eeworld.com.cn/thread-428154-1-1.html

[4]https://www.digikey.com/en/maker/projects/what-is-a-realtime-operating-system-rtos/28d8087f53844decafa5000d89608016

[5]https://www.beningo.com/how-to-choose-between-bare-metal-rtos-and-gpos/

[6]https://mp.weixin.qq.com/s/PUwee79SWTj7diXS02knIw

[7]https://lembergsolutions.com/blog/choosing-right-rtos-your-embedded-system

· END ·

Welcome to set us as “starred“, so that you can receive push notifications in the first instance.

Scan to follow: Automotive Development Circle, reply “Auto“

Get free Autosar introductory and practical materials!

Scan to add the assistant and reply “join the group”

Communicate face-to-face with electronic engineers