Choosing a suitable embedded operating system can consider the following factors:
The first is the application. If the embedded device you want to develop is closely related to network applications or is a network device, then you should choose embedded Linux or uCLinux, rather than uC/OS-II.
The second is real-time performance. There is no absolute number to tell you what is hard real-time and what is soft real-time; the boundaries between them are quite vague, and this relates to what kind of CPU you choose, its main frequency, memory, and other parameters. If you use embedded Linux with real-time patches, such as Monta Vista Linux (version 2.4.17), the worst-case scenario is only 436 microseconds, while 99.9% of the time is within 195 microseconds. Considering the improvements in real-time performance of the latest Linux, it can fit 90~95% of various embedded system applications. Of course, if you want faster real-time response, such as high-speed A/D conversion requiring interrupt latency within a few microseconds, using uC/OS-II may be appropriate. Of course, using traditional embedded operating systems like Vxworks can also meet such strong real-time requirements.
The Linux system has developed into a very mature and reliable GPOS (General Purpose Operating System), and because it follows the GPL protocol and opens all system source code, it is very easy to trim. More importantly, compared with other open-source GPOS or RTOS, the Linux system supports various processors, development boards, and provides various software development tools. At the same time, the Linux system has excellent support for networking and graphical interfaces. Clearly, choosing the Linux operating system has huge advantages in product development cycles and cost control.
With many economic and technical advantages, Linux is being used by more and more embedded devices. The market share of Linux in embedded systems is increasing, and here are the reasons why most products choose the Linux system:
-
Linux supports a wide variety of hardware devices.
-
Linux supports a large number of applications and network protocols.
-
Linux has good scalability, from small consumer electronics to large, bulky telecom-grade switches and routers can use Linux.
-
Unlike traditional proprietary embedded operating systems, deploying Linux does not require paying patent fees.
-
Linux attracts a large number of active developers, who can quickly support new hardware architectures, platforms, and devices.
-
More and more hardware and software vendors, including almost all top chip manufacturers and independent software developers, now support Linux.
The typical definition of a real-time system is as follows: “A real-time system is one where the correctness of the computation results depends not only on the correctness of the computation logic but also on the time at which the results are produced. If the completion time does not meet the requirements, it can be said that the system has a problem.” In other words, regardless of what tasks the real-time application performs, it not only needs to perform the task correctly but also must complete it in a timely manner.
People can easily misunderstand real-time, thinking that real-time means fast enough speed; in fact, real-time does not mean fast speed. The key to real-time is to ensure completion time, rather than original speed, because speed performance is related to hardware and can be obtained by building a fast hardware platform (processor, memory subsystem, etc.). Real-time behavior is a software issue aimed at ensuring that critical operations can be completed within the guaranteed time.
Real-time processes do not affect their scheduling in the execution environment; rather, the environment affects the scheduling of real-time applications. In other words, real-time processes are usually associated with a physical event, such as an interrupt from peripheral devices. Thus, it is clear that the reasons affecting real-time are interrupt response delays, which can be subdivided into interrupt delay, interrupt processing, and scheduling delay in the Linux system. Generally speaking, depending on the user’s acceptable level of the impact caused by exceeding the time limit, real-time can be further divided into soft real-time and hard real-time.
Soft Real-Time
Most people agree that soft real-time means that operations have time constraints. If the operation is not completed after exceeding the time limit, the quality of experience will decline, but it will not have fatal consequences. A desktop workstation is an excellent example of needing soft real-time functionality. When editing a document, you expect to see results on the screen immediately after pressing a key. When playing an MP3 file, you expect to hear high-quality music without noise, pops, or interruptions. If these so-called soft real-time events miss the deadline, the results may be less than ideal and lead to a decline in the quality of experience, but it is not disastrous.
Hard Real-Time
Hard real-time characteristics are that missing the deadline can lead to serious consequences. In a hard real-time system, if the deadline is missed, the consequences are often disastrous. Of course, “disaster” is relative. But if your embedded device is controlling the fuel flow of a jet engine and it fails to respond promptly to the pilot’s commands or changes in operating characteristics, fatal consequences are inevitable.
Here, we summarize the definitions of soft real-time and hard real-time. For soft real-time systems, if the deadline is missed, the system’s computed value or result may be less than ideal. However, for hard real-time systems, if a certain deadline is missed, the system has failed, and it may lead to disastrous consequences.
Although the Linux system is powerful, practical, and easy to develop software, and provides familiar standard APIs for programmers, it was originally designed as a GPOS (General Purpose Operating System). Its purpose is to build a complete and stable open-source operating system, minimize the average response time, improve throughput, and focus on the overall functional requirements of the operating system to achieve better average performance. (In operating systems, we can simply understand throughput as the total number of events the system can handle in a unit of time.)
Therefore, when designing the Linux process scheduling algorithm, the main consideration was fairness, meaning that the scheduler tries to allocate available resources evenly to all processes needing the processor and ensures that each process can run. However, this design goal is contrary to the needs of real-time processes, so standard Linux does not provide strong real-time performance.
The lack of strong real-time performance in Linux limits its application in embedded applications, mainly due to several factors such as kernel preemptibility, process scheduling methods, interrupt handling mechanisms, clock granularity, etc. Specifically as follows:
(1) Process Scheduling
The Linux system provides scheduling policies that comply with POSIX standards, including FIFO scheduling policy (SCHED_FIFO), real-time scheduling policy with time slices (SCHED_RR), and static priority preemptive scheduling policy (SCHED_OTHER). The default scheduling policy for Linux processes is SCHED_OTHER. Although this scheduling method allows processes to fairly use CPU and other resources, it does not guarantee that time-critical or high-priority processes will execute before low-priority processes, which severely affects system real-time performance. Therefore, setting the scheduling policy of real-time processes to SCHED_FIFO or SCHED_RR seems to give the Linux system the ability to perform real-time scheduling based on process priority, but the problem is that the Linux system supports preemptive scheduling policies in user mode but does not fully support preemptive scheduling policies in kernel mode. Thus, tasks running in Linux kernel mode (including system calls and interrupt handling) cannot be preempted by other higher-priority tasks, leading to priority inversion issues.
(2) Kernel Preemption Mechanism
Linux system processes run in two modes: user mode and kernel mode. When a process runs in user mode, high-priority processes can preempt it and complete tasks well; however, when a process runs in kernel mode, even other high-priority processes cannot preempt it. When a process enters kernel mode through a system call, real-time tasks must wait for the system call to return before they can obtain system resources. This contradicts the high-priority task operation required by real-time systems.
Of course, this situation has significantly improved since the release of the Linux 2.6 kernel. The kernel after version 2.6 is preemptive, meaning that processes can be preempted whether they are in kernel mode or user mode. The kernel after version 2.6 provides the following three preemption modes for users to choose from:
PREEMPT_NONE – No forced preemption. The overall average delay is low, but occasionally some longer delays may occur. It is most suitable for applications where overall throughput is the primary design criterion.
PREEMPT_VOLUNTARY – The first phase of reducing delays. It places additional voluntary preemption points in some critical sections of kernel code to reduce delays. However, this comes at the expense of overall throughput.
PREEMPT/PREEMPT_DESKTOP – This mode allows preemption anywhere in the kernel except in critical sections. This mode is suitable for applications that require soft real-time performance, such as audio and multimedia. This is also at the expense of overall throughput.
(3) Interrupt Masking
Linux disables interrupts during interrupt handling to complete tasks faster and more safely, but during this time, even if higher-priority real-time processes occur, the system cannot respond and must wait until the current interrupt task is completed. This situation can lead to increased interrupt delays and scheduling delays, reducing the real-time performance of the Linux system.
(4) Coarse Clock Granularity
The clock system is an important component of a computer, equivalent to the pulse of the entire operating system. The minimum time interval that the system can provide is called clock granularity, and clock granularity is directly proportional to the delay of process responses; that is, the coarser the granularity, the longer the delay. However, smaller clock granularity is not always better. In the same hardware environment, smaller time granularity can lead to increased system overhead and reduced overall throughput.
In the Linux 2.6 kernel, the clock interrupt frequency range is 50-1200Hz, with a period of not less than 0.8ms, which is obviously not sufficient for applications requiring response accuracy of tens of microseconds. In embedded Linux systems, to improve overall throughput, the clock frequency is generally set to 100HZ or 250HZ.
Additionally, the system clock is responsible for soft timing. As the number of soft timers increases, timer conflicts can occur, increasing the system load.
(5) Virtual Memory Management
Linux uses virtual memory technology, allowing processes to run in a virtual space much larger than the actual space. In time-sharing systems, the virtual memory mechanism is very suitable, but for real-time systems, this is unbearable. Frequent page swapping can make it impossible for system processes to complete within the specified time.
To address this issue, the Linux system provides a memory locking feature to prevent memory pages from being swapped out during real-time processing.
(6) Differences in Mutual Access to Shared Resources
When multiple tasks mutually access the same shared resource, it is necessary to prevent data from being damaged; the system usually uses a semaphore mechanism to solve the mutual exclusion problem. However, in real-time systems based on priority scheduling, the semaphore mechanism can easily cause priority inversion, where low-priority tasks occupy resources of high-priority tasks, preventing high-priority tasks from running.
Although since version 2.6.12, the Linux kernel has been able to achieve soft real-time performance of less than 10 milliseconds on faster x86 processors, if predictable, repeatable microsecond-level delays are to be achieved, making the Linux system better suited for embedded real-time environments, modifications to the Linux system are required while ensuring its functionality. The next section will introduce methods to improve Linux real-time performance through real-time patches.
According to the requirements of real-time systems and the characteristics and performance analysis of Linux, there are various methods for modifying the real-time performance of standard Linux, with two main reasonable categories: directly modifying the Linux kernel source code and dual-kernel methods.
1. Directly Modifying the Linux Kernel Source Code
Making minor modifications to the Linux kernel code does not make large-scale changes to the kernel. In compliance with the GPL protocol, directly modifying the kernel source code can transform Linux into a fully preemptive real-time system. Core modifications are focused on local areas and will not fundamentally change the Linux kernel. Furthermore, some changes can be completed through Linux’s module loading, where the system loads the functionality module when it needs to handle real-time tasks and dynamically unloads it when not needed.
Currently, the mainline kernel version released on kernel.org does not support hard real-time. To enable hard real-time functionality, patches must be applied to the code. Real-time kernel patches are the result of collective efforts to reduce the latency of the Linux kernel. This patch has multiple code contributors and is currently maintained by Ingo Molnar. The patch website is: www.kernel.org/pub/linux/kernel/projects/rt/.
When configuring the kernel code that has been patched for real-time, we find that the real-time patch adds a fourth preemption mode called PREEMPT_RT (real-time preemption). The real-time patch adds several important features to the Linux kernel, including using preemptive mutexes instead of spinlocks; in addition to the areas protected by preempt_disable(), preemptive functionality is enabled throughout the kernel. This mode can significantly reduce jitter (variability in delay) and provide predictable low latency for real-time applications with high latency requirements.
However, this method has the problem that it is difficult to guarantee that, under any circumstances, GPOS program code will never obstruct RTOS’s real-time behavior. In other words, modifying the Linux kernel makes it difficult to ensure that the execution of real-time processes will not be disturbed by unpredictable activities carried out by non-real-time processes.
2. Dual-Kernel Method
In fact, the rationale for the dual-kernel design is that people do not believe that the standard Linux kernel can fulfill its real-time commitments under any circumstances because the GPOS kernel itself is complex, and more program code usually leads to more uncertainty, making it impossible to meet predictability requirements. Moreover, the rapid development of the Linux kernel means that it will bring significant changes in a short period, making it difficult to maintain synchronization with the method of directly modifying the Linux kernel source code.
The dual-kernel method involves using two mutually cooperating, working system kernels on the same hardware platform, where one kernel provides precise real-time multitasking processing, and the other kernel provides complex non-real-time general functions.
The essence of the dual-kernel method is to run the standard Linux kernel as an ordinary process on another kernel. The key modification part is to add an interrupt control simulation layer between Linux and the interrupt controller, which becomes part of its real-time kernel. This interrupt simulation mechanism provides a flag to record the interrupt status of Linux. Generally, interrupts are only disabled when modifying key code in core data structures, so the interrupt response is minimal. The advantage is that it can achieve hard real-time performance and easily implement a new scheduling strategy.
For ease of use, the real-time kernel is usually provided by a set of dynamically loadable modules, or it can be compiled directly in the Linux source tree like any other general subsystem. Common dual-kernel real-time patches include RTLinux/GPL, RTAI, and Xenomai, where RTLinux/GPL only allows real-time applications to be provided in the form of kernel modules; RTAI and Xenomai support executing real-time programs in user space with MMU protection. Below, we will analyze RTAI and Xenomai.
Figure 1. RTAI (left) and Xenomai (right) real-time kernels in the layered structure of Linux
Figure 1 shows the layered structure of the dual-kernel system consisting of RTAI and Xenomai real-time kernels and the standard Linux kernel. It can be seen that the two have slightly different organizational forms, and unlike Xenomai, which lets ADEOS control all interrupt sources, RTAI intercepts them and uses ADEOS to notify Linux of interrupts that RTAI is not interested in (i.e., interrupts do not affect real-time timing). The purpose of this mixed process is to improve performance because, in this case, if the interrupt is to wake up a real-time task, it avoids the overhead of managing interrupts by ADEOS. From this, it can be seen that RTAI’s real-time performance should be better than that of Xenomai.
Although RTAI has better real-time performance, it lacks support for ARM, and its update speed is very slow, resulting in long project development cycles and high research and development costs.
In contrast, Xenomai focuses more on real-time performance in user space, providing multiple sets of APIs compatible with mainstream commercial RTOS, and has broad hardware support. Applications built on it can maintain high real-time performance, and its stability and compatibility are better; in addition, the Xenomai community is active, closely following mainstream kernel updates, and supports various architectures, with good support for ARM.
Xenomai is a real-time development framework for the Linux kernel. It aims to seamlessly integrate into the Linux environment to provide comprehensive, interface-independent hard real-time performance for user-space applications. Xenomai is based on an abstract real-time operating system core, which can be used to construct various real-time interfaces on a core of general real-time operating system calls. The Xenomai project began in August 2001. In 2003, it merged with the RTAI project to launch RTAI/fusion.
In 2005, due to different development philosophies, the RTAI/fusion project separated from RTAI to become the Xenomai project. In contrast, the RTAI project is committed to achieving the lowest possible latency from a technical standpoint; Xenomai, in addition, places great emphasis on scalability, portability, and maintainability. The Xenomai project will support Ingo Molnar’s PREEMPT_PT real-time preemption patch, which is a significant difference from the RTAI project. Both RTAI and Xenomai have developer community support and can serve as an open-source alternative to VxWorks.
Xenomai is based on Adeos (Adaptive Domain Environment for Operating System) technology, which aims to provide a flexible and extensible adaptive environment for operating systems; in this environment, multiple identical or different operating systems can coexist and share hardware resources. In systems based on Adeos, each operating system runs in an independent domain, each domain can have its own address space and software abstraction layers such as processes and virtual memory, and these resources can also be shared by different domains. Unlike traditional methods of coexisting operating systems, Adeos inserts a software layer under the existing operating system, providing certain primitives and mechanisms to the upper-layer multiple operating systems to achieve hardware sharing. The application mainly provides a nanokernel (microkernel) for the “hardware-kernel” interface, enabling systems based on the Linux environment to meet hard real-time requirements.
Xenomai fully utilizes Adeos technology. Its primary goal is to help people port applications that rely on traditional RTOS to the GNU/Linux environment as smoothly as possible, avoiding the need to rewrite the entire application. It provides a simulator that simulates the API of traditional real-time operating systems, making it easy to port applications to the GNU/Linux environment while maintaining good real-time performance. The core technology of Xenomai is to use a real-time microkernel to construct these real-time APIs, also known as “Skin.” Xenomai achieves various traditional RTOS application programming interfaces through this interface variation technology, facilitating the migration of traditional RTOS applications to GNU/Linux. Figure 2 describes the layered architecture of Xenomai with Skin.
Figure 2. Xenomai Layered Structure with Skin Interface
From Figure 2, it can be seen that the Xenomai system contains multiple abstraction layers: the Adeos nanokernel operates directly on top of the hardware; above Adeos is the hardware abstraction layer (HAL) related to the processor architecture; the central part of the system is an abstract real-time kernel running on top of the hardware abstraction layer, which implements a series of basic services of general RTOS.
These basic services can be provided by Xenomai’s native API or by client APIs targeting other traditional RTOS built on the real-time kernel, such as RTAI, POSIX, VxWorks, uITRON, pSOS+, etc. The client APIs are designed to be compatible with the traditional RTOS applications they support for migration to Xenomai, ensuring that applications do not need to be completely rewritten during the migration process. This feature ensures the robustness of the Xenomai system. The Xenomai/Linux system provides both user space and kernel space modes for user programs; the former is implemented through system call interfaces, while the latter is implemented through the real-time kernel. The user space execution mode ensures the reliability and good soft real-time performance of the system, while kernel space programs can provide excellent hard real-time performance.
1.Learn FPGA Well and Easily Achieve Your Engineering Dream
2.Foreign Programmers Seek Help on What to Do After 40, See What Replies They Get!
3.Oh My! As an Electronic Engineer, You Are Still Using Baidu to Find Information?
4.To Learn STM32, You Must Understand These Five Embedded Operating Systems!
5.How Important is the RF Filter? This Article Will Make You Understand
6.Many People Think FPGA is Difficult to Learn Because They Haven’t Summarized That Digital Electronics Ultimately Leads to Analog Electronics!
Disclaimer: This article is a network reprint, and the copyright belongs to the original author. If there are any copyright issues, please contact us, and we will confirm the copyright based on the copyright certificate you provide and pay remuneration or delete the content.