Follow the + star public account and never miss exciting content
Material source | Internet
RTOS plays an important role in embedded development. So, when do you need to use RTOS?
■ When exactly is a real-time operating system needed?
Do most embedded projects still require a real-time operating system? It's a good question given the speed of today's high-performance processors and the availability of live patches for Linux, Windows, and other general-purpose operating systems (GPOS).
The answer lies in the nature of embedded devices. These devices are typically produced in thousands, or even millions, of units, and even a $1 reduction in hardware costs per unit can save manufacturers a small fortune. In other words, these devices can't afford the cost of a multi-million-hertz processor (let alone cooling).
For example, in the automotive telematics market, a typical 32-bit processor runs at about 600 MHz, which is much lower than the processors commonly found in desktops and servers. In such an environment, there are huge economic advantages to real-time operating systems designed to extract extremely fast, predictable response times from low-end hardware.
In addition to cost savings, real-time operating systems provide services that make many computing problems easier to solve, especially when multiple activities compete for a system's resources. For example, consider a system where users expect (or need) to respond to input immediately. With a real-time operating system, developers can guarantee that operations initiated by the user will take precedence over other system activities, unless more important activities must be performed first (for example, operations that help protect the user's security).
Also consider a system that must meet quality of service (QoS) requirements, such as a device displaying live video. If any part of a device's content delivery relies on software, then it will experience dropped frames at a rate that the user considers unacceptable, and the device is unreliable. However, with a real-time operating system, developers can precisely control the order in which software processes are executed and ensure playback occurs at an appropriate and consistent rate.
■ Real-time operating systems are unfair
In the embedded industry, the need for real-time "hard" time is still prevalent. The question is: What do real-time operating systems do that GPOS doesn't? And, how useful are the current real-time extensions for some GPOS? Can they provide reasonable real-time operating system performance?
Let's start with task scheduling. In GPOS, the scheduler typically dispatches threads and processes to CPUs using a "fair" policy. Such a strategy can achieve the high overall throughput required by desktop and server applications, but does not guarantee that high-priority, time-critical threads will execute before lower-priority threads.
For example, GPOS may reduce the priority assigned to a high-priority thread, or dynamically adjust a thread's priority to ensure fairness to other threads in the system. Therefore, high-priority threads may be preempted by low-priority threads. Furthermore most GPOS have unbounded scheduling delays: the more threads there are in the system, the longer it takes GPOS to schedule a thread of execution, and any of these factors can cause high-priority threads to miss deadlines, even when on a high-speed CPU.
Additionally, a high-priority thread can run uninterrupted until it completes what it needs to do, unless of course it is preempted by a higher-priority thread. This approach, known as priority-based preemptive scheduling, allows high-priority threads to meet their deadlines even if many other threads are competing for CPU time.
If you need to learn more practical operating system development technologies, you can participate in the training courses at Niuka Academy. This course is created by senior RTOS development experts from top international equipment manufacturers. It systematically teaches practical application technologies such as Kernel, BSP, and IDE, and assists with Use the actual development board for case practice operations. Click on the poster to learn more.
■ Preemptive kernel
In most GPOS, the os kernel is not preemptible. Therefore, a high-priority user thread can never preempt a kernel call but must wait for the entire call to complete—even if the call is made by the lowest-priority process in the system. Additionally, when a driver or other system service (usually executed in a kernel call) performs an exe cut on behalf of a client thread, all priority information is usually lost. This behavior can cause unpredictable delays and prevent critical activities from completing on time.
On the other hand, in real-time operating systems, kernel operations are preemptible. As in GPOS, preemption may not occur within time windows, which in a well-designed real-time operating system are very short, typically on the order of hundreds of nanoseconds. In addition, real-time operating systems place an upper limit on preemption latency and how long interrupts are disabled; this upper limit allows developers to determine worst-case latency.
To achieve consistent predictability and timely completion of critical activities, the real-time operating system kernel must be as simple and elegant as possible. The best way to achieve this simplicity is to design a kernel that contains only services with short execution paths. By excluding work-intensive operations (such as process loading) from the kernel and assigning them to external processes or threads, RTOS designers can help ensure that there is an upper bound on the longest non-preemptible code path through the kernel.
In some GPOS, the kernel adds a certain degree of preemption. However, the time intervals during which preemption is unlikely to occur are still much longer than those in typical real-time operating systems; the length of any such preemption interval will depend on the longest critical section of any module (e.g., networking) in the GPOS kernel. Additionally, a preemptible GPOS kernel does not handle other conditions that can cause infinite delays, such as the loss of priority information that occurs when a client calls a driver or other system service.
■ Avoid priority inversion
In GPOS, and even in real-time operating systems, low-priority threads may inadvertently prevent high-priority threads from accessing the CPU, a situation called priority inversion. When infinite priority inversion occurs, critical deadlines can be missed, leading to consequences ranging from anomalous system behavior to outright failure. Unfortunately, priority inversion is often overlooked during system design. There are many examples of priority reversal, including the Mars Explorer project in July 1997.
Generally speaking, priority inversion occurs when two tasks of different priorities share a resource and the higher-priority task cannot obtain the resource from the lower-priority task. To prevent this situation beyond a limited time interval, real-time operating systems can provide a selection of mechanisms not available in GPOS, including priority inheritance and priority cap emulation. It's impossible to do justice to both mechanisms, so let's focus on an example of priority inheritance. .
First, we must consider how task synchronization can lead to blocking, and how blocking can in turn lead to priority inversion. Suppose two tasks are running, Task 1 and Task 2, and Task 1 has higher priority. If Task 1 is ready to execute but must wait for Task 2 to complete its activity, it will block. This blocking may be due to synchronization; for example, Task 1 and Task 2 share a resource controlled by a lock or semaphore, and Task 1 is waiting for Task 2 to unlock the resource. Or, it could be because Task 1 is requesting a service that Task 2 is currently using.
Blocking allows Task 2 to run until a condition occurs that Task 1 is waiting for (for example, Task 2 unlocks a resource shared by both tasks). At this point, task 1 begins to execute. The total time Task 1 has to wait is called the blocking factor. If Task 1 is to meet any of its time constraints, this blocking factor cannot vary with any parameters (such as the number of threads or system input). In other words, the blocking factor must be bounded.
Now let's introduce the third task, Task 3, which has a higher priority than Task 2 but lower than Task 1 (see Figure 1). If task 3 is ready to run while task 2 is executing, it will preempt task 2 and task 2 will not be able to run again until task 3 blocks or completes. Of course, this new task will increase the blocking factor of Task 1; that is, it will further delay the execution of Task 1. The total delay introduced by preemption is a priority inversion.
Figure 1 Task 1 is waiting for Task 2 to complete an activity, when Task 3 preempts Task 2. This new task further delays the execution of Task 1
In fact, multiple tasks can preempt Task 2 in this way, creating an effect called chain blocking. In this case, Task 2 may be preempted indefinitely, creating infinite priority inversion, and Causing Task 1 to be unable to meet any of its deadlines.
This is where priority inheritance comes in. If we return to our scenario and have Task 2 run at Task 1's priority during synchronization, Task 3 will not be able to preempt Task 2, thus avoiding priority inversion (see Figure 2).
Figure 2 Task 2 inherits the higher priority of Task 1, thus preventing Task 3 from preempting Task 2. Task 3 no longer delays the execution of Task 1.
■ Partition scheduler
For many systems, ensuring resource availability is critical. If a critical subsystem is deprived of, say, CPU cycles, then the services provided by that subsystem become unavailable to users. For example, in a denial-of-service (DoS) attack, a malicious user can bombard the system with requests that require high-priority processes to handle. This process can overload the CPU, interrupting other processes' CPU cycles, making the system unavailable to users.
Security vulnerabilities are not the only cause of process starvation. In many cases, adding software features to a system can push the system "to the breaking point" and cause existing applications to take up a lot of CPU time. An application or service that is running in a timely manner no longer responds as expected or required. Historically, the only solutions to this problem have been either to retrofit the hardware or to recode (or redesign) the software—both unpopular options. To solve these problems, system designers need a partitioning scheme that enforces CPU operations through hardware or software to prevent processes or threads from monopolizing the CPU cycles required by other processes or threads. Because real-time operating systems already provide centralized access to the CPU, memory, and other computing resources, real-time operating systems are the best choice for performing CPU partition operations.
Some real-time operating systems provide a fixed partition scheduler. Using this scheduler, system designers can divide tasks into groups or partitions and allocate a percentage of CPU time to each partition. Using this approach, tasks in any given partition will not consume more CPU time than the partition's statically defined percentage. For example, assume a partition is allocated 30% of the CPU. If a process in that partition is subsequently targeted by a denial of service attack, it will consume no more than 30% of the CPU time. This allocated limit allows other partitions to maintain their availability; for example, it ensures that user interfaces (such as remote terminals) remain accessible. Therefore, the operator can access the system and troubleshoot the problem without having to press the reset switch.
However, there is a problem with this approach. Because the scheduling algorithm is fixed, a partition can never use CPU cycles allocated to other partitions, even if those partitions do not use their allocated cycles. This approach wastes CPU cycles and prevents the system from handling peak demand. As a result, system designers must use more expensive processors, tolerate slower systems, or limit the number of features the system can support.
■ Adaptive partitioning
Another partitioning scheme, called adaptive partitioning, addresses the shortcomings of static partitioning by providing a more dynamic scheduling algorithm. Like static partitioning, adaptive partitioning allows system designers to reserve CPU cycles for a process or group of processes. Therefore, designers can ensure that the load on one subsystem or partition does not affect the availability of other subsystems. However, unlike static methods, adaptive partitioning can dynamically reallocate CPU cycles from less busy partitions to partitions that can benefit from extra processing time partitioning budget, enforced only when the CPU is fully loaded. Therefore, the system can handle peak scheduling applications without changing their scheduling behavior. In addition, designers can dynamically reconfigure partitions to optimize system performance. Participate in the automotive operating system technology training at Niuka Academy to learn more practical technologies. Scan the QR code at the end of the article to register.
■ “Dual” core
GPOS, including Linux, Windows, and various flavors of unix, generally lack the real-time mechanisms discussed so far. To fill this gap, GPOS vendors have developed a large number of live extensions and patches. For example, there is a dual-core approach in which GPOS runs as a task on top of a dedicated real-time core (see Figure 4). Therefore, these tasks can preempt GPOS when they need to execute it, and only hand the CPU over to GPOS when it has finished its work.
Unfortunately, tasks running in the real-time kernel can only make limited use of existing system services in GPOS - file system, network, etc. In fact, if a real-time task requests any service from GPOS, then the task will be subject to the same priority processing requirements and achieve 100% utilization, while enjoying the benefits of resource guarantees.
Equally important, adaptive partitioning can be overlaid on top of existing systems without the need for redesign or code modification. System designers can simply launch existing POSIX-based applications in partitions, and the real-time operating system scheduler ensures that each partition receives its allocated budget. Within each partition, each task is scheduled according to priority-based preemption rules.
Figure 3 Adaptive partitioning prevents high-priority tasks from consuming more than their allocated CPU percentage unless the system contains unused CPU cycles. For example, tasks A and D can run within the time allocated to partition 3 because tasks E and F do not require the remaining budgeted CPU cycles.
Issue preventing GPOS process from deterministic behavior. Therefore, new drivers and system services must be created specifically for the real-time kernel, even though similar services already exist for GPOS. Moreover, tasks running in the real-time kernel cannot benefit from the powerful MMU-protected environment that most GPOS provides for regular, non-real-time processes. Instead, they run unprotected in kernel space. Therefore, real-time tasks containing common coding errors (such as corrupted C pointers) can easily lead to fatal kernel errors. This is a problem because most systems that require real-time also require high reliability. To further complicate matters, different implementations of the dual-core approach use different APIs. In most cases, services written for GPOS cannot be easily ported to the real-time kernel, and tasks written for one vendor's real-time extension may not run on another vendor's extension.
Figure 4 In a typical dual-core implementation, GPOS runs as the lowest priority task in a separate real-time core.
These solutions point to the real difficulty and enormous scope of enabling GPOS to support real-time behavior. This is not a question of "real-time operating systems are good, GPOS is bad". GPOS such as Linux, Windows and various unixes all work well as desktop or server operating systems. However, they fall short when forced into deterministic environments for which they were not designed, such as in-vehicle telematics units, medical devices, real-time control systems, and continuous media applications.
■ Extend operating system application-specific requirements
Whatever their disadvantages may be in deterministic environments, there are benefits to using them.
These advantages include support for widely used APIs and support for Linux's open source model. Using open source, developers can tailor operating system components to their application-specific needs, saving significant time troubleshooting. Real-time operating system vendors cannot ignore these benefits. Broad support for POSIX APIs (the same APIs used by Linux and various flavors of Unix) is an important first step. The same goes for providing well-documented source code and custom toolkits to meet the specific needs and design challenges of embedded developers.
The architecture of the real-time operating system also plays a role. For example, a real-time operating system based on microkernel design can make operating system customization fundamentally easier to implement than other architectures. In a microkernel real-time operating system, only a small set of basic operating system services (e.g., signals, timers, scheduling) reside in the kernel itself. All other components—drivers, file systems, protocol stacks, applications—run outside the kernel as independent, memory-protected processes (see Figure 5). In fact, as user-space programs, such extensions become as easy to develop as standard applications because they can be debugged with standard source-level tools and techniques.
Figure 5 In a microkernel real-time operating system, system services run as standard user space processes, thus simplifying the task of operating system customization.
For example, if a device driver attempts to access memory outside its process container, the operating system can identify the responsible process, indicate the location of the error, and create a process dump file that can be viewed with source-level debugging tools. A dump file can contain all the information the debugger needs to identify the source code causing the problem, as well as diagnostic information such as the contents of data items and function call history.
This architecture also provides better fault isolation and recovery: if a driver, protocol stack, or other system service fails, it can do so without disrupting other services or the operating system kernel. In fact, Software Oversight can continuously monitor for such events and dynamically restart offending services without resetting the entire system or involving users in any way. Similarly, drivers and other services can be stopped, started, or upgraded dynamically without shutting down the system.
These benefits should not be overlooked - the biggest disruption to real-time performance is an unscheduled system reboot! Even a planned reboot to incorporate a software upgrade can disrupt operations, albeit in a controlled way. To ensure that deadlines are always met, developers must use operating systems that are continuously available, even in the event of software glitches or service upgrades.
■ A strategic decision
Real-time operating systems help make complex applications both predictable and reliable; in fact, a real-time operating system's precise control of time increases reliability that cannot be achieved with GPOS. (If a GPOS-based system does not work correctly due to incorrect timing behavior, then we can reasonably say that the system is unreliable.) However, choosing the right RTO can itself be a complex task. The underlying architecture of the real-time operating system is an important criterion, but so are other factors. These include:
• Flexible choice of scheduling algorithm - Does the real-time operating system support the choice of scheduling algorithm (FIFO, round-robin, sporadic scheduling, etc.?) Can the developer allocate algorithms on a thread-by-thread basis, or does the real-time operating system force him to allocate one algorithm to all threads in the system?
• Time Partitioning - Does the real-time operating system support time partitioning to give a process a certain percentage of CPU cycles? Such guarantees simplify the work of integrating subsystems from multiple development teams or vendors. They also ensure that critical tasks remain available and meet their deadlines, even if systems are subject to denial-of-service (DoS) attacks and other malicious attacks.
• Support for multi-core processors - The ability to migrate to multi-core processors has become fundamental to a wide range of high-performance designs. Does the real-time operating system support a selection of multi-processing models (symmetric multi-processing, asymmetric multi-processing, bound multi-processing) to help developers take full advantage of multi-core hardware? Does the system tracing tool support the real-time operating system to allow developers to diagnose and optimize Multi-core system performance? Without tools that highlight resource contention, excessive thread migration, and other issues common in multi-core designs, optimizing multi-core systems can quickly become an arduous, time-consuming task.
• Tools for remote diagnostics - Since many embedded systems cannot tolerate downtime, real-time operating system vendors should provide diagnostic tools that can analyze the behavior of the system without interrupting the services provided by the system. Look for a vendor that provides runtime analysis tools for system analysis, application analysis, and memory analysis.
• Open development platform - Does the RTOS vendor provide a development environment based on an open platform (such as Eclipse), allowing developers to "plug in" their favorite third-party tools for modeling, version control, etc.? Or is the development environment based on proprietary technology?
• Graphical User Interface - Whether the real-time operating system uses the original graphics library, or supports multiple human interface technologies (HTML5, Qt, OpenGL ES, etc.) and provides advanced graphics capabilities such as multi-layer interfaces, multi-head displays, accelerated 3D rendering and Real window system? Can the look and feel of the gui be easily customized? Can guis display and input multiple languages (Chinese, Korean, Japanese, English, Russian, etc.) at the same time? Can 2D and 3D applications easily share the same screen? Standard APIs - Does a real-time operating system lock developers into proprietary APIs, or does it provide certified support for standard APIs like POSIX and OpenGL ES, making code more portable between other environments? Furthermore, does the real-time operating system provide full support for the API, or does it only support a small part of the defined interface?
• Standard APIs - Does a real-time operating system lock developers into proprietary APIs, or does it provide certified support for standard APIs such as POSIX and OpenGL ES, making code more portable between other environments? Furthermore, does the real-time operating system provide full support for the API, or does it only support a small part of the defined interface?
• Middleware for digital media – Flexible support for digital media is becoming a design requirement for a range of embedded systems, including car radios, medical devices, industrial control systems, media servers, and, of course, consumer electronics. A system may need to handle multiple media sources (devices, streams, etc.), understand multiple data formats, and support multiple DRM schemes. By providing well-designed middleware for digital media, real-time operating system vendors can eliminate the extensive software effort required to connect to multiple media sources, organize data, and initiate appropriate data processing paths. Additionally, a well-designed middleware solution There will be flexibility to support new data sources, such as next-generation iPods, without requiring modifications to the user interface or other software components.
Choosing a real-time operating system is a strategic decision for any project team. When RTOS vendors provide clear answers to the above questions, you'll be able to choose the one that's best for now and in the future.
Statement: The material of this article comes from the Internet, and the copyright belongs to the original author. If there is any copyright issue with the work, please contact me to delete it.
------------ END ------------
●Column "Embedded Development"
●Embedded column selected tutorials
Follow the official account and reply " Add Group " to join the technical exchange group according to the rules, and reply " 1024 " to view more content.
Click " Read the original text " to view more sharing.