Transform Linux into a real-time operating system

Transform Linux into a real-time operating system-general Linux technology-Linux programming and kernel information. The following is a detailed description. In the past, many embedded systems were not an operating system, a provider's proprietary core, or a DOS Operating System Extension. Obviously, these methods cannot meet the requirements of embedded system development today! Although some existing commercial real-time operating systems provide a very small core and multi-task development environment, their performance is not ideal and does not meet the requirements of the real-time embedded market.
　　
Therefore, people are looking at general operating systems (such as Windows, Solaris, and Linux) and want to "transform" them into real-time operating systems. Generally, these operating systems have powerful functions, complex structures, and easy Secondary Development of Software. They are highly practical and provide standard APIs that programmers are familiar. In addition, these operating systems provide some support for real-time software development. However, these operating systems are still insufficient for embedded system development. Embedded systems require high reliability, application tailoring, and higher real-time performance than general operating systems.
　　
As a solution for embedded system development, Linux has unique advantages among many general operating systems.
　　
First, the tailoring of private business operating systems such as Windows and Solaris is strictly controlled by sellers. This greatly limits the depth of developer tailoring. Linux follows the GPL protocol and opens the source code of all systems, making it easy to crop.
　　
Secondly, compared with other open-source general operating systems (such as FreeBSD), Linux has a strong advantage in supporting multiple processors, development boards, and software development tools.
　　
Linux was originally designed and developed as a general operating system, but provided some real-time processing support. This includes supporting real-time functions in Most POSIX standards, supporting multi-task, multi-thread, and rich communication mechanisms.
　　
Linux also provides POSIX-compliant scheduling policies, including FIFO Scheduling Policies, time slice rotation scheduling policies, and static preemptible Priority Scheduling Policies. The default scheduling policy is the third. Linux also provides the Memory Lock function to avoid page replacement during real-time processing and provides a real-time signal mechanism that complies with POSIX standards.
　　
A fatal problem is that Linux supports preemptible Scheduling Policies in user mode, but does not support preemptible Scheduling Policies in core mode. In this way, tasks (or system calls) Running in Linux core State cannot be preemptible by other tasks with higher priority, which will cause priority reversal. In addition, the interrupt handling handle of the Linux operating system cannot be scheduled, and cannot be scheduled based on the priority. In the real-time system, the interrupt handling handle is the same as the real-time task, and can be scheduled by the system scheduler with a priority.
　　
In addition, we also care about clock precision related to task response time and priority reversal problems caused by resource sharing. In Linux, the default time interval for hardware clock interruption is 10 ms. All software clocks are triggered by hardware. However, the simple synchronization mechanism (mutex) does not support priority inheritance, which may result in priority reversal.
　　
Independent Core Method
　
Linux, as an independent kernel of a real-time system, refers to the design of a completely independent real-time core, but its API is compatible with the Linux core. The theoretical basis of this method is that an excellent real-time operating system must fully consider the real-time requirements of the system at the beginning of its design and be able to provide standard-compliant APIs. This implementation method is attractive to many POSIX-compatible real-time proprietary system providers.
　　
The limitation of this method is that a completely independent real-time core is designed without the original Linux core, which makes it difficult to inherit some advantages of the Linux system, in particular, some advantages related to Linux core cannot be obtained. For example, the Linux core supports a wide range of hardware, and the Linux core features superior reliability and stability. In addition, this method does not modify the Linux core code to develop the Real-Time core, but instead re-designs a Real-Time core on the Linux system. Such development does not require open source code. Therefore, some advantages of Linux based on open source code are bound to be damaged. Finally, any development results based on the Linux core cannot be easily applied to the real-time core.
　　
Of course, this implementation method also gets a lot of benefits from the Linux system. Thanks to the support of the Linux system, the real-time core does not need to be implemented "really. In addition, developers familiar with Linux systems can quickly become familiar with the real-time systems developed using this method. People will naturally think of Linux as a development platform for embedded systems. In addition, if the real-time system API is a subset of the Linux system API, we can simulate the application development and debugging only on the Linux host, saving the trouble of remote debugging!

Compatibility with Linux APIS is an important indicator for evaluating such real-time systems. If a real-time system is compatible with all Linux APIs, it allows all Linux applications and libraries to run and use on it. Therefore, this will bring about a huge benefit. all third-party software available on Linux can be used on it. Of course, developing a real-time system that is compatible with all Linux APIS is by no means easy, especially for a single developer.
　　
Therefore, a large number of third-party software cannot be easily transplanted to real-time systems. This deficiency also compromises the Linux advantages!
　　
Dual-core method
　
This method uses two system cores that work together on the same hardware platform. One core provides precise real-time multi-task management, and the other core provides complex non-real-time common functions.
　　
This method is implemented by adding a Real-Time core layer at the bottom of the Linux operating system. The real-time core is responsible for hardware management and provides real-time task management. The real-time core also uses the software to "simulate" the use of the underlying hardware in conventional Linux systems/prohibit interruptions, rather than the real operation of the interrupt control register. The Linux core is regarded as the task with the lowest priority in the real-time core for scheduling. It is only scheduled when no real-time task can be run.
　　
The key to this method is that all non-real-time tasks running on the general Linux core must support preemptible scheduling. In this way, accurate real-time assurance of real-time core can be achieved without any impact. Because the real-time core is very small and does not increase the load of the entire system, all these real-time software with strict real-time requirements for Development provide a powerful guarantee.
　　
The disadvantage of this method is that the development of real-time tasks is directly oriented to the small real-time core that provides precise real-time services, rather than the powerful conventional Linux core. Therefore, real-time tasks run on the system core layer, which means these real-time tasks can run on a level without memory protection. Therefore, an error in a real-time task may paralyze the entire system! Even worse, the development of these real-time tasks is faced with a small real-time core, rather than directly using Linux APIs and third-party software and runtime libraries.
　　
This development mode implies that we must perform static decomposition on the application. It is divided into real-time and non-real-time parts. In most cases, this is a good thing. It forces developers to break down application systems into real-time subsystems and non-real-time subsystems. But obviously, this development mode also limits the application type! This approach, however, is not suitable for all applications. In some applications, the boundaries between real-time and non-real-time parts are not very clear, and there may be different degrees of Soft Real-Time parts.
　　
Another disadvantage of this method is that the Development Mode integrates two irrelevant dimensions of real-time applications ?? Function requirements and real-time requirements. It requires that the real-time requirements of applications be limited to the functional requirements provided by the real-time core. However, the real-time core provides very limited function support. Of course, we can also expand core real-time functions, such as adding real-time network functions. However, the newly added part is likely to overlap the existing functions of the Linux core, leading to unnecessary system expansion and compromising the value of this method.

Core modification method

This method is based on the existing Linux system's support for real-time software development, source code-level modifications to make Linux a real-time operating system. This method is also consistent with the Linux philosophy. Any product based on Linux core source code modification must follow the GPL protocol and open source code to all software personnel. Once many people think it is useful, someone will maintain it, or mix it in the general Linux core, or separate a Real-Time Linux branch.
　　
The central principle of this method is to carefully select some changes to meet a series of related real-time Linux development requirements. In addition, because these changes are relatively local, they will not fundamentally change the core of Linux. In addition, some changes can be completed through the conventional Linux module loading method. The system can dynamically load the function module as needed, and unmount the function module as needed.
　　
For example, one of the modifications is the core preemptible scheduling. Changing the core from a non-preemptible type to a preemptible type is a major structural change that may cause many problems. However, many problems have been solved when Linux supports SMP. Therefore, the core preemptible modification can simply use the SMP hook. Another modification point is the previously mentioned scheduling of the interrupt handling handle. Some modifications are global, such as modifying the system clock service to provide a higher-precision "Heartbeat" without increasing unnecessary system load, or provide a mutex mechanism at the core to support priority inheritance.

Resource Core Method
　　
This method is designed to address the limitations of preemptible scheduling policies with fixed priority in traditional real-time operating systems. The preemptible Scheduling Algorithm with a fixed priority has no temporary protection between tasks. Therefore, the foreseeable task response time depends on the prediction of the execution time of all higher-priority tasks. In such a system, predictability is global and may be affected by a bad task. In addition, this kind of static view of real-time systems is also inappropriate. In many real-time applications, the real-time system is expected to dynamically adjust the task attributes based on the resources obtained by the application, in order to obtain the optimal effect.
　　
The resource core method is a resource-centric method that guides the Real-Time core to provide accurate, guaranteed, and preemption methods for obtaining system resources. As long as the resources required by the real-time application can be allocated by the Core background Resource Management Program, the real-time core allows the real-time application to be configurable. Therefore, the core of real-time is to provide the foundation for real-time application construction ?? From a simple real-time system to a complex real-time system, you can dynamically change the real-time task attributes and their priorities throughout the system.
　　
The biggest advantage of this method is that the system is robust, accurate, and foreseeable in real time. Another advantage is that applications can dynamically adjust their attributes based on actual conditions. In addition, this method is very suitable for embedded system development.