Embedded RTOS (Real Time Operating System) has made a big splash in recent years. Embedded MCU, has long been out of the main frequency of only 8MHz era, now embedded controller chip, the main frequency can be as high as 600MHz, and ordinary MCU can easily run at 64MHz. not only the main frequency of the qualitative leap, and Arm Cortex-M series of MCUs, the early stage of the kernel design has also been added to support the RTOS of the native kernel instructions. However, although RTOS is called a “real-time operating system”, is it really real-time? What does real-time mean here?

Bare Metal, RTOS, GPOS

If you want to figure out the “real-time” of RTOS, you should first understand the three forms of development in the current embedded field - bare metal development (Bare Metal), RTOS, GPOS (General-Purpose Operating System). General-Purpose Operating System (GPOS), its main features are as follows: Bare Metal: Bare Metal systems do not use an operating system. Instead, the application code runs directly on the hardware without operating system support, and the code can directly interact with and access the hardware. Bare-metal development is very effective in resource-constrained scenarios, such as 8-bit or 16-bit MCUs, or when there is only 32KB of flash memory and 2KB of RAM. Of course, bare-metal development can also be used when resources are abundant, such as when the system has high real-time requirements. The EEWorld forums have many engineers who favor bare-metal development. RTOS: As the name implies, RTOS is designed to serve real-time applications that provide predictable execution times and time-sensitive applications whose key features are responsiveness and determinism. RTOS is more convenient than bare metal. To use an RTOS, a system should have at least 64 KB of flash memory, 4 KB of RAM, and a processor clock of 80 MHz or higher.RTOSs are typically used in systems with more complex timing requirements than bare metal, often managing real-time requirements while dealing with communication stacks such as TCP/IP, MQTT, USB, Wi-Fi, and so on. While such systems can be developed in bare metal, RTOS can simplify the design, speed up time-to-market, and make software maintenance easier.Another key point of RTOS is the software development of added features such as service management, task synchronization, scheduling, and inter-task communication.RTOS allows for consideration of tasks that preempt each other, which in turn allows for more complex application design.GPOS: This consists of mainly Linux, Windows, etc., designed to run a variety of software applications. These operating systems are designed for user interaction, provide some sort of interface, either a command line interface (CLI) or a graphical user interface (GUI), are designed to run multiple applications (often with multiple threads), and provide other benefits such as resource/file management and device drivers. User interaction is usually the main focus of GPOS design, so some latency is acceptable. Also, the hardware is usually a 32+ bit processor with 200MHz or more and several megabytes of flash memory. Because of the complexity of Linux itself, real-time Linux (such as Ubuntu's Real-Time Linux), which is in between RTOS and Linux, has also been created. The core concept of real-time Linux is “preemption”, which means interrupting the currently executing thread to immediately process higher priority events. the choice between RTOS and real-time Linux depends on system-specific latency requirements, as well as the need for overhead and resource efficiency. While real-time Linux provides a powerful solution for many scenarios, a dedicated RTOS may still be preferable in certain critical embedded systems. If a project needs to balance real-time requirements with the flexibility to run a variety of applications, then Real-Time Linux will provide a more versatile solution.

Figure. 1

What RTOS can't do

From bare metal to RTOS, in fact, engineers there will be a lot of confusion, EEWorld forums, engineers jorya_txj has used their own past experience, to tell their own understanding of RTOS: he said, at present, contacted a few people from the bare metal to RTOS, contact with some of the project, there are some feelings, for those who do not understand the RTOS, it may feel that this thing is very Mystery, can solve any bare-bones can not solve things, but things are often not so. Naked only do one thing is the most efficient, if you do one thing naked are very hard, rtos can not solve the hardware liability things, on the contrary, the use of rtos will be worse. For example, suppose the system has a 20us frequency interrupt on cortex-m3, the maximum time consumed in the interrupt is 10us, then the interrupt left for rtos is only 10us, this 10us also need to call rtos queue to send api. although some systems can respond to 20us interrupt, but can not guarantee that 10us can complete the call of api and out of the interrupt processing. The system can respond to a 20us interrupt, but there is no guarantee that the call to the api and the interrupt can be completed within 10us. Even if it can be guaranteed, the execution efficiency of the tasks outside will be very, very bad. Most RTOSes cannot respond to interrupts within 1us. That is to say, after the interrupt occurs, it takes 1us to process the user's interrupt function. The above two examples can only start from the hardware design, to solve this problem from the root. For example, the first problem can be used to reduce the frequency of interrupts using a dedicated chip or controller. The second problem can be accomplished using FPGAs to complete the precise timing, etc. RTOS is more like an army management decision makers, rather than a front of the front warriors. The more complex a system tends to RTOS the greater the advantage of a system tends to be simpler, the more useless ROTS. RTOS is often not a lifesaver, hardware design problems still need to be solved by hardware design, can not be brought to the software side of the solution to get away with it, even if the software can be solved by a fluke this time, the next time may be unable to solve the problem again, does not have the generality.

On real-time, engineers' questions

EEWorld forum, senior engineer Xin Xin has posted a special discussion of this issue - “real-time” in the end what. When he was asked what “real-time” really is, he replied in a brainwave: “It's a fast response, such as opening a web page, it's best not to wait 1ms ......”. But the response was that he didn't even know what real-time was. In fact, real-time refers to the response within a specified time, rather than the faster the better. According to the response time in microseconds, milliseconds and seconds, the real-time response of the system is divided into three kinds, RTOS belongs to the hard real-time: the first is hard real-time (Hard real-time), is to respond to the immediate event, absolutely can not miss the time limit of the event processing, and any missed deadline is considered as a system failure. Any missed deadline is considered a system failure. It is close to the timely response of RTOS that we usually talk about, which does not emphasize how fast the reflection is, but to be completed before the specified deadlines. The second is Soft real-time (Soft real-time), is allowed to often miss the deadline, as long as the tasks are executed in a timely manner, their results will continue to be valuable. Close to WINDOWS, Linux desktop version of such commonly used systems, soft real-time refers to the statistical sense of real-time, generally large overall throughput or overall response speed, but can not guarantee that a particular task in the specified time to complete. The third type is quasi-real-time (Firm real-time), where the system is not considered to have failed even if it fails to meet a deadline, possibly more than once (i.e., for multiple requests). In addition, once the deadline for a particular request has passed, the response to the request (answer to a query, result of a task, etc.) will be worthless (the usefulness of the result after the deadline is zero). Other engineers have their own understanding of real-time. According to them, real-time is when the system's response time to an event meets the demand, so that it can be considered real-time because the event can always be processed in response within a limited time. Specifically, the response time of each event is related to the real time. In a normal working environment, there is no uncertainty and such a system is called a real-time system. So, it can be said that the so-called real-time is not really real-time. Well-known embedded engineer StrongerHuang has similarly written: Strictly speaking, RTOS is not a real-time response and deal with urgent matters, but only in a very short time (generally ms level) on the response, giving the impression that real-time in response. For example, RTOS real-time response to the important configuration of the system tick (SysTick), by definition, the system tick value (beat) the larger the faster the response, but the system scheduling also need to take up time, so the tick value is not the larger the better. For example, real-time response can be achieved with interrupts, but hardware interrupts can only make an “emergency notification”, not a (time-consuming) execution action. According to other engineers, RTOS real-time means that it can be executed within a certain time window. It does not mean immediate execution, so RTOS is a real-time operating system. Hardware interrupts exit immediately after the execution of high-priority tasks, so the priority configuration is reasonable, can be in us or even ns level response. In fact, well-written bare-metal response and RTOS is almost the same, but the biggest advantage of RTOS is task scheduling, when the complexity of the function can be scheduled through the operating system without worrying about task conflicts.

The four categories of RTOS

In fact, RTOS itself is categorized into four types according to the response level, which are used in different types of embedded systems: 1. Hard RTOS: Hard RTOS is widely used in embedded solutions that are responsible for dealing with mission-critical tasks and require precise time constraints. This means that certain events must be executed at a predetermined moment, not a second earlier or later, as this can cause serious problems or even physical damage to the system. Examples include automotive cruise control and railroad signaling systems. 2. Soft RTOS: Soft RTOS is suitable for embedded systems where the lack of predefined time constraints does not seriously affect the processes involved and the overall system operation. It allows time deadlines to be set for the execution of specific tasks, but missing these deadlines does not stop the system from running. Examples include in-flight entertainment and voice chat applications.3. Quasi-RTOS: A quasi-RTOS is a middle ground between a hard RTOS and a soft RTOS, and works as follows: with a quasi-RTOS, a system task can miss a deadline without having an impact on the process and system operation. However, there is a limit to the number of tasks that can be missed, and if they exceed the allowable number, it will result in serious system errors and delays. Examples include robotic assembly lines and telecommunication networks.4. Deterministic RTOS: Deterministic RTOS is a perfect match for embedded systems where timing must always be precise. This type of real-time embedded programming allows for predicting the time required to execute tasks of varying priority and complexity. Deterministic scheduling will allow us to set time frames for accurate execution of critical tasks. It makes the embedded system run predictably, consistently and reliably.

Figure. 2