For many embedded systems, a well-designed real-time operating system (RTOS) allows the development engineers to master the system to perform any tasks or respond to any key event time, meet system real-time requirements. In order to understand how RTOS implements real-time requirements through system scheduling strategies, this article describes the concept of preemptive scheduling, can preemptive, priority inheritance, and interrupt processing.
When designing industrial control systems or medical devices, most engineers and system design engineers will consider that RTOS is required. However, doctors such as Internet routers, car entertainment systems, and multimedia equipment need to use RTOS? Can a general-purpose operating system like Linux or Windows? Typically, these products require RTOS, but this problem is often only realized until the later stage of the design phase.
RTOS is not only beneficial for many embedded systems, but also it is important. It is important to recognize this. For example, a device that plays a MPEG format movie, if it relysses the software to implement its entire content transmission, there may be a high-lost frame rate that the user is difficult to accept. However, by using RTOS, the system design engineer can accurately control the execution order of the software process, ensuring playback according to the given media rate. Most of the above cases apply to systems that users want to respond immediately to input. Through RTOS, developers can guarantee that the user's operation can always get a timely response unless a more important operation (such as an operation that helps to protect user security) must be executed first.
In summary, a good RTOS supports the developer control system to perform any task or a time to respond to any important event, and can meet the final deadline requirements of the task in a predictable and fully consistent form. However, if RTOS crashes, these final deadlines cannot be satisfied. Therefore, RTOS must provide a high degree of reliability. In particular, it must provide a mechanism that quickly and intelligently recover from software failures without restarting.
Gemple schedule
In a universal operating system like Linux, the "fair" scheduling policy is used in the CPU of threads and processes. Such strategies provide good overall performance, but cannot guarantee high priority, and strict threads for time requirements will take precedence over lower priority threads. In fact, the operating system sometimes interrupts high priority threads to provide CPU time for low priority threads. As a result, it is possible to easily miss the final deadline for time requirements, even in a high-speed high-end processor running.
In RTOS, the thread is performed in the order of its priority. If a high priority thread is ready to run, it will take over the CPU from any low priority process that may be running within a short, limited time interval. In addition, the high priority thread can be run uninterrupted until it has completed what you need to do - of course, it is under the premise that it is not prejudieted by the higher priority process. This method is to seize the schedule, ensuring that the high priority thread always meets its final deadline, regardless of how many other threads are competing CPU time.
By reasonably controlling thread priority, developers can significantly improve many application response speeds that are very important to users. However, the control priority may be a double-edged sword that it may potentially result in the low priority process without obtaining the CPU time. To ensure high priority processes and threads, ensure that the key that does not make other processes are in the "hunger" state to limit their execution, and the developers can be controlled by adjusting or controlling the execution or in the process of responding. Limit these activities consumed CPU time proportions and support the low priority process to get sharing of CPUs.
Priority control can benefit many applications, including the media player (MP3, WAV, MPEG2 formats) mentioned earlier. The media player needs to realize the rate required for normal playback (eg 44kHz audio, 30fps video). Under this restriction, a reading thread and a display thread can be designed to depends on a programmable timer to wake up, buffer, or display a frame to enter the sleep state until the next timing trigger. This provides a adjustment mechanism that supports priority settings above normal user activities and below key system functions. In other words, if there is no more important task to be run, the media play will always be performed at a given media rate. Worst case
The preemptive scheduling is only valid in a short, limited period of time in a short, limited period of time. Otherwise, the system will not predict how long it takes to take a given operation. Therefore, the supplier of RTOS in any sales process mode must provide the worst situation for the following two time intervals: thread switching time, i.e., when the two threads are in the same process, from the last command to execute a thread to the execution The time passed by the first instruction of the scheduled thread; a context switch time, it defines the same, but only for the two threads in different processes.
Threads can be regarded as the smallest "execution unit", while the process is asked as a "container" of one or more threads, and the process defines the address space that the thread will be executed therein. Obviously, the front and rear relationship between the worst situation will be slower than the worst case thread, although the difference may be slightly in a good RTOS design.
Putting all threads in a few big processes will be wrong because the thread provides the switching speed faster. Although the line can achieve parallel processing advantages Therefore, it is appropriate for some design, but a process that divides a plurality of memory protection makes the code easier to debug, providing better error isolation and recovery capabilities, and allows the system to dynamically upgrade.
Can preempt the kernel
In most universal operating systems, the kernel of the operating system cannot be preemptive. As a result, a high priority process cannot seize a kernel call, but must wait for the entire call to complete, even if this call is initiated by the low priority process in the system. In addition, when the driver or other system service that is often performed in the kernel call, all priority information is often lost, which has led to unpredictable delays and blocks on time of key activities.
In RTOS, the kernel operation is grabbing. Although there will still be some time window, there may be no preemption in these time windows, but these time intervals should be quite short, usually at hundreds of nanoseconds. In addition, there must be a time limit for prelimating or interrupted or interrupted, so that developers can determine the waiting time in the worst case.
In order to achieve this goal, the operating system core must be as simple as possible, only services with shorter execution paths are included in the kernel, and any operation that requires a lot of work (such as process loading) must be arranged to external processes or threads. This method helps to ensure that the longest non-sewage code path is a time limit through the kernel.
Priority inheritance
However, setting a high priority for a process does not always guarantee that the process can seize the low priority process. Sometimes, a state called priority inversion, in which a low priority process will prevent higher priority processes in "inadvertent" to occupy the CPU. The priority inversion may be manifested in several forms. In order to prevent this, RTOS must provide a function called priority inheritance.
Assume that the system has three processes: a (low priority), B (medium priority), z (high priority). Here z is a "server" process that serves a service for A and B. See Figure 1.
Now suppose A has requested Z to perform a calculation, during which time, suddenly B requires Z to serve. Because B has a higher priority than A, it is generally considered Z will immediately hang a request and turn to B service. But the actual situation is not the case because the Z ratio B has a higher priority. As a result, b cannot block Z complete its current work, that is, responds to A. From the effect, the low priority process A takes up the CPU time of higher priority process B, which is the cause of the introduction of priority. By using the priority inheritance mechanism provided by RTOS, the system can let Z inherit A low priority in the case where a request is issued. In this way, B can preempt a request at any time.
If an application is distributed in several processors connected through the network, RTOS should also support distributed priority inheritance, which can process requests from multiple processors in order of priority. If there is no priority inherit, a multiprocessor system may fall into an unlimited priority inversion and deadlock.
Interrupt processing
In order to obtain a timely response to external events, the time for minimizing hardware interruptions to perform the first code to perform the interrupt is important. This time interval is called interrupt delay, in order to ensure that the interrupt delay is as small as possible, a good RTOS should support generate interrupts in almost all time. As mentioned in the internal nuclear session, some important code segments do need temporary shielding interrupts. This maximum shielding time is typically defined as the largest interrupt delay.
In some cases, the hardware interrupt processor must schedule and run a higher priority thread (eg, in a driver). In such a case, the interrupt processor will return and indicate an event will be processed. Such processing will introduce a second form of delay-scheduling delay, which must be considered in the design. The scheduling delay is the time between the last instructions of the user's interrupt processor and the execution of the driver thread first instruction.
Multiple hardware interrupts may occur at the same time in an embedded system. For example, in a patient monitoring system, when a sensor records a change in the patient's heartbeat and the network card receives the data from the network, the nurse presses the touch screen. Obviously, some interrupts (such as heart rate changes) should be treated immediately, while others can delay. By providing support for nested interrupts, RTOS supports embedded systems prioritize higher priority interrupts.
How to improve reliability
We have understood how to make RTOS predictable, but how to achieve its reliability? The answer depends to a large extent on the architecture of the RTOS.
For example, in real-time execution mode architecture, most or all software components are run in a single memory address space, including operating system kernels, network protocol stacks, device drivers, applications, and more. Although it is very efficient, this architecture has two obvious defects: 1. One pointer in any component is wrong, regardless of this error, can destroy the operating system kernel or any other components, resulting in unpredictable behavior and The collapse of the entire system; 2. It is difficult to dynamically repair or replace any faulty components. In most cases, the system reset is the only choice when these problems occur.
Some RTOS, like Linux, try to solve this problem by using a single core architecture. In this architecture, the user's application runs in isolation and protected memory address space. If an application tries to access the data other than its address space, the memory management unit (MMU) will notify the operating system, and the operating system may take protection, such as termination of the error process. However, such an operating system needs to bind most or all drivers, file systems, and other system services to the kernel. Therefore, an error in any component may bring catastrophic kernel failures.
The third method is to provide a more accurate fault isolation using a micro-kernel architecture, which is based on the micron nuclear architecture based on the operating system like QNX Neutrino. Microena has two clear features: 1. Only a small kernel containing basic OS services (such as semaphore, timer, task scheduling, etc.) in the operating system kernel. All other components including drivers, file systems, protocol stacks, and user applications are running in the internal core external to protect memory. There is a problem with system service no longer be used as an isolated fault point, but is terminated and restarted before it destroys other services or operating system kernels. 2. All components can communicate via messaging, a well-defined communication mechanism guarantees data exchange under premise that maintaining each other's safety isolation. Suitable message delivery can also be used as a virtual "software bus", allowing almost any software components, or even a device driver being dynamically added or replaced, which is a key for systems that must provide continuous services. Claim.
Compared to traditional operating system architecture, microuclear support embedded devices have won significantly faster average repair time (MTTR). For example, if a device driver fails, the following is possible: The operating system can terminate the driver, reclaim the resources it is using, and restart it, this process usually takes only a few milliseconds.
Although messaging-free microennal RTOS typically provides better fault tolerance and dynamic upgrade capabilities than traditional operating systems, there are also some views that message delivery has increased overhead. In practical applications, if it is true, the performance of messaging can be close to the memory bandwidth of the underlying hardware. For example, a micro-kernel RTOS can adopt a multiPart message and threaded message data direct copying of the message data to ensure system performance can reach the level of traditional process communication (IPC) methods. It is confirmed by some organizations such as Dedicated Systems (Website: www.omimo.be), etc. Performance.
Strategic decision
RTOS helps a complex application with predictability and reliability. Of course, choosing a suitable RTOS itself is a complex task, while the underlying architecture of RTOS is an important basis for choice, and there are some other factors, including:
1. Flexible selection of scheduling algorithms. RTOS should support the selection of scheduling algorithms (first in first out (FIFO), Round Robin, sporadic scheduling, etc.) and support these algorithms in units. In this way, engineers can do not have to use an algorithm to use all threads in the system.
2. Graphical User Interface (GUI). RTOS uses the original graphic library or support multi-layer interface, multiplexed, 3D rendering, and other advanced graphics features true window systems? Can I make it easy to customize the appearance of GUI? GUI supports simultaneous display and enter a variety of languages (Chinese, Korean, Japanese, English, Russian, etc.)?
3. Remote diagnostic tool. Because of many embedded systems, interrupt system runs to detect and maintain unacceptable. RTOS vendors should provide diagnostic tools that can analyze the behavior of the system under the premise of uninterrupted system services. To find suppliers that provide code coverage, application assessment, tracking analysis, and memory analysis tools.
4. Development platform. The development environment provided by RTOS providers is based on open platforms like Eclipse, allowing engineers to embed the favorite third-party tools to model, version control? Or is the development environment based on patented technology?
5. Internet function. RTOS supports pre-integrated IPv4, IPv6, IPSec, SCTP, and IP filtering sets such as NAT functions? Does it support embedded web browsers? The browser should have scalable package mode and can draw web pages on a small screen. It should also support standards like HTML 4.01, XHTML 1.1, SSL 3.0, and WML 1.3.
6. Standard API. Is RTOS to define you in the proprietary API? Or it provides full support for standard APIs like POSIX, which makes the code to other operating systems, or be easier to transplant the code from other operating system? In addition, the RTOS used provides full consistency API or only a subset of the defined interface? For example, the latest version of POSIX.1 contains approximately 1,300 interfaces. 7. Multi-process technology. Can RTOS support symmetrical multiprocessing and distributed multiprocessing technology to improve application performance and capacity? If so, is it necessary to redes your app, or RTOS can allocate the application to multiple processors?
8. Source Code Toolkit. Is the RTOS vendor provided a custom kit with a detailed document that enables RTOS to meet design requirements? Does suppliers offer driver development kits that make it easy to develop drive custom hardware?
9. For many companies, choose an RTOS is a strategic decision. RTOS suppliers provide a clear answer to the above questions, you will choose to make RTOS that is right and future.
Author: Paul N. Leroux technical analyst Email: paull@qnx.com QNX Software Systems Ltd.
