To select a suitable embedded operating system, consider the following factors:
The first is the application. If you want to develop an embedded device that is closely related to network applications or is a network device, then you should choose to use embedded Linux or uCLinux instead of uC/OS-II.
The second is real-time. No absolute number can tell you what is hard real-time, what is soft real-time, the boundary between them is also very vague, which is related to what kind of CPU you choose, its frequency, memory and other parameters have a certain relationship. If you use embedded Linux with technologies such as real-time patching, such as Monta Vista Linux (version 2.4.17), the worst case is only 436 microseconds, and 99.9% is less than 195 microseconds. Taking into account the latest real-time improvements in Linux, it can be adapted to 90-95% of various embedded system applications. Of course, if you want faster real-time response, such as high-speed A/D conversion requires several microseconds or less of interrupt latency, it may be appropriate to use uC/OS-II. Of course, using a traditional embedded operating system like Vxworks can also meet such strong real-time requirements.
Why Linux Operating System
The development of Linux as a GPOS (General Operating System) has been very mature and reliable so far, and since all GPL protocols are followed, opening all system source code is very easy to tailor. More importantly, compared to other open source GPOS or RTOS, the Linux system supports multiple processors, development boards, and a variety of software development tools. At the same time, the Linux system has excellent network and graphical interface support. Obviously, choosing the Linux operating system has great advantages in terms of product development cycle and cost control.
With many economic and technological advantages, Linux is being used by more and more embedded devices. Linux's occupancy rate in the embedded system market is getting higher and higher. The following are reasons why most products choose the Linux system:
Linux supports a wide variety of hardware devices.
Linux supports a lot of applications and network protocols.
Linux scales well, from small consumer electronics to large, bulky carrier-grade switches and routers that can use Linux.
Unlike traditional proprietary embedded operating systems, deploying Linux does not require payment of royalties.
Linux attracts a large number of active developers and can quickly support new hardware architectures, platforms, and devices.
More and more hardware and software vendors, including almost all top-tier chip makers and independent software developers, now support Linux.
What is real-time?
The typical definition of a real-time system is as follows: "The so-called real-time system means that the correctness of the calculation results in the system depends not only on the correctness of the calculation logic but also on the timing of the results. If the completion time does not meet the requirements, it can be said that the system has occurred. Problem.†That is, no matter what task the real-time application is doing, it not only needs to do it correctly, but it must also be completed in time.
People can easily misunderstand real-time, thinking that real-time speed is fast enough, in fact, real-time does not mean fast. The key to real-time is to guarantee the completion time, not the original speed. Because the speed performance is related to the hardware, you can build a fast hardware platform (processor, memory subsystem, etc.) to get the required performance. The real-time behavior is a software problem whose goal is to allow critical operations to be completed within the guaranteed time.
Real-time processes do not affect their own scheduling in the execution environment. Instead, the environment affects the scheduling of real-time applications. In other words, a real-time process is usually associated with a physical event, such as an interrupt from a peripheral device. Obviously, the reason for the impact on real-time is the interrupt response delay. It can be subdivided into interrupt latency, interrupt processing, and scheduling delay in Linux systems. In general, the real-time can be divided into soft real-time and hard real-time in response to the user's acceptable degree of influence over the time limit.
Soft real time
Most people agree that soft real time means that the operation has time limits. If the operation is not completed after the time limit is exceeded, the quality of experience will be reduced, but it will not have fatal consequences. Desktop workstations are an excellent example of soft real-time functionality. When editing a document, you expect to see the result on the screen immediately after pressing the key. When playing MP3 files, you expect to hear high quality music without any noise, pop or interruption. If these so-called soft real-time events miss the time limit, the results may not be satisfactory and lead to a decrease in the quality of the experience, but this is not catastrophic.
Hard real time
The hard real-time feature is that missing deadlines can cause serious results. In a hard real-time system, if you miss the time limit, the consequences are often catastrophic. Of course, "disaster" is relative. But if your embedded device is controlling the fuel flow of a jet engine and it does not respond to changes in command or operational characteristics of the pilot in a timely manner, the fatal consequences are inevitable.
Here, we summarize the definition of soft real-time and hard real-time. For soft real-time systems, if the time limit is missed, the system's calculated value or result will be less than ideal. However, for hard real-time systems, if you miss a certain time limit, the system will fail, and it may cause disastrous consequences.
Factors that limit the real-time performance of standard Linux operating systems
Although the Linux system is powerful, practical, and easy to redevelop software, it also provides standard APIs that programmers are familiar with. However, since the Linux system was initially designed as a GPOS (General Operating System), its purpose is to build a complete and stable open source operating system, minimize the average response time of the system, improve throughput, and pay attention to the overall functional requirements of the operating system. To achieve better average performance. (In the operating system, 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 is fairness. That is, the scheduler allocates the available resources as much as possible to all the processes that require the processor, and ensures that each process runs. However, this design goal is contrary to the needs of real-time processes, so standard Linux does not provide strong real-time.
The lack of real-time performance of Linux system makes it have some limitations in embedded applications. It is mainly controlled by several factors such as kernel preemption, process scheduling, interrupt handling, and clock granularity. The details are as follows:
(1) Process scheduling
The Linux system provides POSIX-compliant scheduling policies, including FIFO scheduling strategy (SCHED_FIFO), real-time scheduling strategy with time-slice rotation (SCHED_RR), and static priority preemptive scheduling strategy (SCHED_OTHER). The default scheduling policy of the Linux process is SCHED_OTHER. Although this scheduling method allows the process to use the CPU and other resources fairly, it does not guarantee that time-critical or high-priority processes will precede low-priority execution. Seriously affect the real-time system. Then, setting the scheduling policy of the real-time process to SCHED_FIFO or SCHED_RR seems to make the Linux system capable of real-time scheduling based on the process priority. However, the problem is that the Linux system supports the preemption of the scheduling strategy in user mode, but not in the kernel mode. Full support for preemptive scheduling strategies. Such tasks (including system calls and interrupt handling) running in the Linux kernel state cannot be preempted by other higher priority tasks, causing priority reversal problems.
(2) Kernel preemption mechanism
The system process of Linux is divided into user mode and kernel mode. When a process runs in user mode, a process with a high priority can preempt the process and can complete the task better; but when the process runs in kernel mode, even other high-priority processes cannot preempt the process. When a process enters kernel mode through a system call, the real-time task must wait for the system call to return before it can obtain system resources. This is inconsistent with the operation of high-priority tasks required by real-time systems.
Of course, this situation has been significantly improved since the release of the Linux 2.6 kernel. The kernel after Linux 2.6 is preemptive, which means that the process may be preempted regardless of whether it is in kernel mode or user mode. The Linux 2.6 kernel provides the following three preemption modes for the user to choose.
PREEMPT_NONE - There is no mandatory preemption. The overall average latency is lower, but there are occasionally longer delays. It is best suited for applications that have the primary design criteria of overall throughput.
PREEMPT_VOLUNTARY - Reduce the first phase of the delay. It places additional display preemption points at key locations in the kernel code to reduce latency. But this is at the expense of overall throughput.
PREEMPT/PREEMPT_DESKTOP - This mode allows the kernel to be preempted anywhere, except 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 will close the interrupt when it performs interrupt processing, so that it can complete its task faster and more securely. However, during this period, even if a higher-priority real-time process interrupts, the system cannot respond and must wait until the current interrupt task. Processing is completed. This situation will lead to an increase in the interrupt delay and scheduling delay, reducing the real-time performance of the Linux system.
(4) Rough clock granularity
The clock system is an important part of the computer and is equivalent to the pulse of the entire operating system. The minimum time interval that the system can provide is called the clock granularity. The granularity of the clock and the delay of the process response are proportional to each other, that is, the coarser the granularity and the longer the delay. However, the smaller the clock granularity, the better. In terms of the same hardware environment, a smaller time granularity will increase the system overhead and reduce the overall throughput rate. In the Linux 2.6 kernel, the frequency of clock interrupts is in the range of 50 to 1200 Hz, and the period is not less than 0.8 ms. It is obviously not satisfactory for applications that require tens of microseconds of response accuracy. In embedded Linux systems, the clock frequency is generally set to 100HZ or 250HZ in order to increase the overall throughput rate.
In addition, the system clock is responsible for soft timing. When the number of soft timers increases gradually, it causes timer conflicts and increases the system load.
(5) Virtual Memory Management
Linux uses virtual memory technology, and the process can run in a virtual space that is much larger than the actual space. In the time sharing system, the virtual memory mechanism is very suitable. However, it is unbearable for the real-time system. Frequent page swapping in and out will make the system process unable to complete within a specified time.
For this problem, the Linux system provides a memory lock function to prevent memory pages from being swapped out during real-time processing.
(6) Mutual exclusion of shared resources
When multiple tasks access the same shared resource exclusively, they need to prevent the data from being destroyed. The system usually uses the semaphore mechanism to solve the mutual exclusion problem. However, in a real-time system based on priority scheduling, the semaphore mechanism can easily cause priority inversion. That is, low-priority tasks occupy high-priority task resources, resulting in high-priority tasks being unable to run.
Although from the 2.6.12 release, the Linux kernel can already achieve soft real-time performance within 10 milliseconds on faster x86 processors. However, if you want to achieve predictable, repeatable microsecond delays, make Linux systems better applied to embedded real-time environment, you need to ensure that the Linux system functions on the basis of its transformation. The next section will introduce how to improve the real-time performance of Linux through real-time patches.
Common real-time Linux transformation program
According to real-time system requirements and Linux's features and performance analysis, there are many ways to transform the real-time nature of standard Linux. The two most reasonable methods are:
Directly modify the Linux kernel source code.
Dual-core method.
1 directly modify the Linux kernel source code
Making minor changes 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 will transform Linux into a fully preemptible real-time system. The core modification is partial, it will not fundamentally change the Linux kernel, and some changes can also be completed through the Linux module loading, that is, the system needs to load the function module when processing real-time tasks, and dynamically uninstall the module when it is not needed.
At present, the mainline kernel version released by kernel.org does not support hard real-time. In order to turn on hard real-time functionality, the code must be patched. The real-time kernel patch is the common result of many efforts, in order to reduce the delay of the Linux kernel. This patch has multiple code contributors and is currently maintained by Ingo Molnar.
When configuring kernel code that has been patched in real time, we find that the real-time patch adds a fourth preemption mode called PREEMPT_RT (real-time preemption). Real-time patches add several important features to the Linux kernel, including the use of preemptable mutexes instead of spin locks; in addition to the areas protected with preempt_disable(), involuntary preemption is turned on everywhere in the kernel ( Involuntary preemption) function. This mode can significantly reduce jitter (changes in latency) and make predictable lower latency for real-time applications that require high latency.
The problem with this approach is that it is difficult to guarantee 100%. In any case, the GPOS program code will never hinder the RTOS's real-time behavior. In other words, by modifying the Linux kernel, it is difficult to guarantee that the execution of real-time processes will not be interfered by the unpredictable activities of non-real-time processes.
2 double-core method
In fact, the reason for the dual-core design is that people do not believe that the standard Linux kernel can fulfill its real-time promise under any circumstances, because the GPOS kernel itself is very complicated, and more program code usually leads to more uncertainty. This will not meet the requirements of predictability. Not to mention the extremely fast development speed of the Linux kernel, which will bring great changes in a very short period of time. The method of directly modifying the Linux kernel source code will be difficult to keep pace.
The dual-core approach is based on the use of two system cores that work together and work together on the same hardware platform. This is accomplished by adding a layer of real-time cores at the bottom of the Linux system. One of these cores provides accurate real-time multitasking, and the other core provides complex, non-real-time generic functionality.
The essence of the dual-core approach is to run the standard Linux kernel as an ordinary process on another core. The key transformation is to add an interrupt-controlled emulation layer between Linux and the interrupt controller as part of its real-time kernel. The interrupt emulation mechanism provides a flag to record the Linux shutdown interrupt. Generally, the interrupt is closed only when the core data structure key code is modified, so the interrupt response is very small. The advantage is that it can be hard real-time, and it can 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 just as any general subsystem is compiled. Commonly used dual-core real-time patches are RTLinux/GPL, RTAI, and Xenomai. RTLinux/GPL only allows real-time applications in the form of kernel modules. RTAI and Xenomai support real-time programs in the user space with MMU protection. Below, we will analyze RTAI and Xenomai.
Figure 1. Hierarchical structure of RTAI (left) and Xenomai (right) real-time kernel in Linux
Figure 1 shows the hierarchical structure of two real-time kernels, RTAI and Xenomai, and a standard Linux kernel that compose a dual-core system. You can see that the two have slightly different organizational forms. Unlike Xenomai, which lets ADEOS control all the interrupt sources, RTAI intercepts them and uses ADEOS to send interrupt notifications that are not of interest to RTAI to Linux (that is, interrupts do not affect real-time interrupts). Timing). The purpose of this mixing process is to improve performance, because in this case, if the interrupt is to wake a real-time task, the overhead of managing interrupts by ADEOS is avoided. From here it can be seen that the real-time performance of RTAI should be better than Xenomai.
Although RTAI (Real-Time Linux Application interface) has good real-time performance, it does not provide enough support for ARM, and the update speed is very slow, resulting in a long project development cycle and high R&D costs.
Compared with RTAI, Xenomai focuses on real-time in user mode, provides multiple APIs compatible with mainstream commercial RTOS, and extensive support for hardware. The application system built on it can maintain high real-time performance and stability. Sex and compatibility are better; in addition, the Xenomai community is active, keeping up with mainstream kernel updates, supporting multiple architectures, and supporting ARM well.
Xenomai is a real-time development framework for the Linux kernel. It hopes to integrate seamlessly into the Linux environment to provide user-space applications with comprehensive, interface-independent hard real-time performance. Xenomai is based on an abstract real-time operating system kernel that can be used to build any number of different real-time interfaces on the core of a common RTOS call. The Xenomai project began in August 2001. In 2003 it merged RTAI/fusion with the RTAI project. In 2005, because of different development concepts, the RTAI/fusion project was separated from the RTAI as a Xenomai project. In contrast, the RTAI project is committed to technically feasible minimum delays; Xenomai is also very much focused on scalability, portability, and maintainability. The Xenomai project will support Ingo Molnar's PREEPPT_PT real-time preemption patch, which is another significant difference from the RTAI project. Both RTAI and Xenomai have developer community support and both can be used as an open source alternative to VxWorks.
Xenomai is implemented based on Adeos (Adaptive Domain Environment for Operating System). The goal of Adeos is to provide a flexible and extensible adaptive environment for the operating system. In this environment, multiple identical or different operating systems can coexist. , share hardware resources. In Adeos-based systems, each operating system runs in a separate domain. Each domain can have separate address spaces and software abstraction layers such as processes and virtual memory. These resources can also be shared by different domains. Different from the traditional operating system coexistence method, Adeos inserts a software layer under an existing operating system, and implements hardware sharing by providing certain primitives and mechanisms to multiple operating systems. The main application is to provide a nano-kernel for the "hardware-kernel" interface so that the system based on the Linux environment can meet the hard real-time requirements.
Xenomai makes full use of Adeos technology. Its primary goal is to help people migrate applications that rely on traditional RTOS to the GNU/Linux environment as smoothly as possible, avoiding completely rewriting applications. It provides a simulator that emulates the API of a traditional real-time operating system, which makes it easy to port applications to the GNU/Linux environment while maintaining good real-time performance. Xenomai's core technology is to use a real-time microkernel to build these real-time APIs, also known as "Skin." Xenomai implements application programming interfaces for many traditional RTOSs through this interface variant technology, facilitating the porting of traditional RTOS applications to GNU/Linux. Figure 2 depicts this Xenomai layered architecture with Skin.
Figure 2. Xenomai hierarchy with Skin interface
As can be seen from Figure 2, the Xenomai system contains multiple abstraction layers: the Adeos nanocore works directly on hardware; on Adeos is a hardware abstraction layer (HAL) related to the processor architecture; The central part is the abstract real-time kernel running on the hardware abstraction layer. The real-time kernel implements a series of basic RTOS basic services. These basic services can be provided by Xenomai's native API (Native) or by client APIs for other traditional RTOSs built on real-time kernels, such as RTAI, POSIX, VxWorks, uITRON, pSOS+, and so on. The client API is designed to be compatible with the Xenomai port of the traditional RTOS-supported applications that it supports, so that the application does not need to be completely rewritten during the migration to the Xenomai/Linux system. This feature ensures the robustness of the Xenomai system. The Xenomai/Linux system provides the user program with two modes of user space and kernel space. The former is implemented through a system call interface, and the latter is realized through a real-time kernel. The user space execution mode guarantees system reliability and good soft real-time performance. The kernel space program can provide excellent hard real-time performance.
Female headphones are specially designed for women, with pink, rose gold or rose red as the main color, which are very popular among female customers. Mainly divided into: headband female headphones, in-ear female earphones, diamond female headphones. With skin-friendly materials, it is comfortable to wear and beautiful in appearance.
Feminine Headphones,Waterproof Headphones,Disposable Headphone,Female Headphones
Shenzhen Linx Technology Co., Ltd. , https://www.linxheadphone.com