CN118519683B - A method and system for operating an embedded hybrid kernel supporting hard real-time - Google Patents

Abstract

The invention discloses an embedded mixed kernel operation method and system supporting hard real time, which relates to the field of embedded equipment, the invention uses an interrupt pipeline to realize the separation processing of hard real time domain IRQ and Linux domain IRQ, judges the IRQ interrupt type, interrupts processing, creates a hard real time thread data structure of the hard real time domain, initializes the hard real time dispatch related data structure and switches to the real time domain for execution, carries out real time thread dispatch, carries out the steps of application program development, the method has the advantages that the function expansion of the Linux embedded operating system in the hard real-time field is realized, the high-instantaneity and high-stability operation of the hard real-time program under the embedded mixed kernel operating system are realized, the universality of the embedded mixed kernel operating system under the hard real-time scene is improved, the problem of the existing real-time operating system on the compatibility of Linux ecology is avoided, and the pressure of a developer for migrating the original application to the embedded mixed kernel operating system supporting the hard real-time is reduced.

Description

A method and system for operating an embedded hybrid kernel supporting hard real-time

Technical Field

The present invention relates to the field of embedded devices, and in particular to an embedded hybrid kernel operation method and system supporting hard real-time.

Background Art

The current embedded Linux operating system was designed with only resource sharing and throughput in mind, with little consideration given to real-time performance. Therefore, improving Linux real-time performance has become a key issue for the stable application and expansion of Linux systems in the embedded field.

Standard Linux has made improvements in real-time performance, which began with Linux 2.6. In Linux 2.6, the following features were implemented to improve system real-time performance:

1. Implement cfs scheduler;

2. Implement POSIX 1003.1b realtime extension;

3. Realize interrupt threading;

4. Implement the preemption mechanism;

5. Achieve high-precision clock.

Despite the improvements made to standard Linux, it still has many real-time limitations, including:

1. The kernel still has a large number of non-preemptible intervals;

2. There are a large number of interrupt shutdown operations, which increases the interrupt delay and reduces the real-time performance of the system;

3. The main interrupts are not threaded (including soft interrupts) and are still the highest priority of the system. As long as the corresponding interrupt time occurs, the kernel will immediately execute the corresponding interrupt processing and soft interrupts. Normal tasks will not be executed until all pending interrupts and soft interrupts are processed. Real-time tasks cannot be guaranteed in real time.

In addition to the above-mentioned technical means of real-time transformation of standard Linux, in order to improve the real-time performance of embedded Linux, the industry also integrates the RT-PREEMPT patch into the kernel to implement RT-PREEMT Linux to improve the real-time performance. RT-PREEMPT has existed in the form of a patch for a long period of time. The main aspects of RT-PREEMT Linux's real-time performance improvement are as follows:

1. Make the kernel as preemptible as possible (except for kernel shutdown interrupt preemption);

2. Except for the system clock, the main interrupts are threaded (interrupt processing can be scheduled);

3. The spinlock lock is converted to rt_mutex (no longer disabling interrupts, allowing preemption, and more suitable for interrupt threading).

Although the above measures have improved the real-time performance of RT-PREEMT Linux, there are still factors that affect the real-time performance, and these factors are difficult to fully control, mainly including the following points:

1. The system directly calls to disable interrupts and preemption, which will continue to increase interrupt and scheduling delays under certain conditions (for example, there is a time-consuming operation to disable preemption in the memory management subsystem);

2. Some driver implementations do not take real-time into consideration, especially drivers such as USB and PCI that exist in the form of driver stacks;

3. Interrupt processing itself. Although most interrupts have been threaded, if there are too many timers or a single timer takes a long time, it will also bring uncertainty to the system response time.

Summary of the invention

In view of the above-mentioned deficiencies in the prior art, the present invention provides an embedded hybrid kernel operation method and system supporting hard real-time, which solves the problems of poor real-time performance and poor compatibility of the existing embedded systems.

In order to achieve the above-mentioned object of the invention, the technical solution adopted by the present invention is:

A method for operating an embedded hybrid kernel supporting hard real-time is provided, comprising the following steps:

S1. Define a high-priority processing stage through the interrupt pipeline so that the interrupt handler registered in the hard real-time domain is run after receiving the interrupt request;

S2, judging whether the current interrupt request is a hard real-time domain interrupt through the interrupt processing program of the hard real-time domain, if so, proceeding to step S3; otherwise, proceeding to step S4;

S3, making the hard real-time domain and the Linux domain both in the interrupt disabled state, processing the hard real-time domain interrupt, and proceeding to step S5;

S4, handing over the current interrupt request to the Linux domain interrupt handler for processing, and making the Linux domain enter the interrupt disabled state, and the hard real-time domain maintains a normal state until the processing of the current interrupt request is completed;

S5. Create a data structure for hard real-time thread scheduling, save key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system;

S6. Configure the scheduling strategy, create and initialize the hard real-time scheduling related data structure, implement task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution;

S7. Schedule hard real-time threads based on scheduling policies.

Furthermore, in step S2, the specific method for determining whether the current interrupt request is a hard real-time domain interrupt is: the current interrupt request is checked in the hard real-time domain by the interrupt handler of the hard real-time domain. If the current interrupt request has a corresponding processing function in the hard real-time domain, the interrupt request is determined to be a hard real-time domain interrupt; otherwise, the interrupt request is determined to be a Linux domain interrupt.

Furthermore, the specific methods for placing the hard real-time domain and the Linux domain in the interrupt disabled state in step S3 are:

Introduce virtual interrupts to replace native Linux kernel interrupts. Modify the virtual interrupt flag to enable virtual interrupts in the Linux domain, and the Linux domain enters the interrupt disabled state.

By modifying the hard real-time domain interface flag bit, the hard real-time domain enters the interrupt disabled state.

Furthermore, the data structure of the hard real-time thread scheduling in step S5 includes a struct hrt_arch_tcb tcb field, a struct hrt_sched *sched field, and a struct hrt_class *sched_class field;

struct hrt_arch_tcb tcb field, used to store architecture related information;

The struct hrt_sched *sched field is used to store information related to hard real-time scheduling;

The struct hrt_class *sched_class field is used to store information related to hard real-time threads.

Furthermore, in step S6, the specific method of creating and initializing the hard real-time scheduling related data structure, realizing task domain switching, driving hot switching, and switching from the non-real-time domain to the real-time domain for execution is:

Create a Linux domain thread, recorded as a shadow thread;

Create and initialize hard real-time scheduling related data structures;

In the native Linux main scheduling interface, add a hijacking operation to set the shadow thread as the hijacking thread of the current CPU;

Trigger a Linux standard schedule, switch to the tail of the next task, call the domain switching process, and complete the switch of the shadow thread from the non-real-time domain to the real-time domain;

Through the hard real-time driver in the hard real-time driver framework, when the task domain is switched, the driver hot switch is completed by referencing the device file descriptor in the hard real-time domain in the hard real-time thread, and the driver is switched from the Linux domain to the hard real-time domain.

The hard real-time domain thread structure is added to the ready queue of the hard real-time scheduler, waiting for the hard real-time scheduler to schedule and run until the CPU is abandoned or the hard real-time domain is exited; if the CPU is abandoned or the hard real-time domain is exited, the remaining part of the process that triggers a Linux standard scheduling is returned and not completed.

Further, the hard real-time driver framework includes predefined real-time class devices and driver implementations, a hard real-time driver programming interface, and a hard real-time driver application interface;

The predefined real-time devices and driver implementations include predefined protocol devices and name devices; all message-oriented devices are protocol devices, and the rest are name devices; applications operate protocol devices through POSIX sockets;

Hard real-time driver programming interface, used to provide clock services, task management services, synchronization services, interrupt management services, non-real-time signal services, real-time memory allocation services, user-mode memory access services, real-time kernel console output services and exception checking mechanism services;

The hard real-time driver application interface is oriented to kernel-mode applications and user-mode applications, and is used to provide interface support for kernel-mode applications and user-mode applications that use the hard real-time driver framework.

Furthermore, the specific method of exiting the hard real-time domain is:

Call the suspend function of the hard real-time domain and set a degradation flag for the hard real-time thread structure;

Enter the main scheduling function of the hard real-time domain, and downgrade the current operation domain from real-time to non-real-time at the entrance of the main scheduling function;

Take out the highest priority ready hard real-time task from the ready queue to replace itself; if there is only hard real-time IDLE task in the current ready queue, return to the previously preempted Linux domain task.

Furthermore, through the alias attribute function in the tool chain, the existing standard POSIX interface is encapsulated and the hard real-time service interface is exposed to users in the form of a dynamic library, so that users can add the dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks.

Provided is an embedded hybrid kernel operating system supporting hard real-time, comprising a hard real-time interrupt management module, a hard real-time task processing module, a hard real-time driver support module, a Linux domain, and a hard real-time domain expanded on the basis of the Linux kernel; wherein the priority of the hard real-time domain is higher than that of the Linux domain;

The hard real-time interrupt management module is used to define a high-priority processing stage through the interrupt pipeline, so that the interrupt handler registered in the hard real-time domain is run after receiving the interrupt request; the interrupt handler of the hard real-time domain determines whether the current interrupt request is a hard real-time domain interrupt, and if so, the hard real-time domain and the Linux domain are both in the interrupt disabled state to process the hard real-time domain interrupt; otherwise, the current interrupt request is handed over to the Linux domain interrupt handler for processing, and the Linux domain is put into the interrupt disabled state, and the hard real-time domain remains in a normal state until the processing of the current interrupt request is completed;

The hard real-time task processing module is used to create the data structure of hard real-time thread scheduling, save the key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system; configure the scheduling strategy, create and initialize the data structure related to hard real-time scheduling, realize task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution; schedule hard real-time threads based on the scheduling strategy;

The hard real-time driver support module is used to define and implement real-time devices and driver implementations by developing a hard real-time driver framework, so that the same hardware device has corresponding device descriptors in both the hard real-time domain and the Linux domain, and the same driver device can be switched between the two domains through driver hot switching.

Furthermore, the system also includes:

The hard real-time application support module is used to encapsulate the existing standard POSIX interface through the alias attribute function in the tool chain, and expose the hard real-time service interface to the user in the form of a dynamic library, so that the user can add the dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks.

The beneficial effects of the present invention are as follows: the present invention realizes the separation processing of hard real-time domain IRQ and Linux domain IRQ through the interrupt pipeline, judges the IRQ interrupt type, interrupts the processing, creates the hard real-time thread data structure of the hard real-time domain, initializes the hard real-time scheduling related data structure and switches to the real-time domain for execution, performs real-time thread scheduling, realizes the expansion of the functions of the Linux embedded operating system in the hard real-time field, realizes the high real-time and high stability operation of the hard real-time program under the embedded hybrid kernel operating system, improves the versatility of the embedded hybrid kernel operating system in the hard real-time scenario, avoids the compatibility problem of the existing real-time operating system with the Linux ecosystem, reduces the pressure on developers to migrate the original application to the embedded hybrid kernel operating system that supports hard real-time, and also reduces the difficulty and complexity of developers using real-time interfaces to develop hard real-time programs.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is a schematic flow diagram of the method;

FIG2 is a schematic diagram of the dual-domain structure of the present system;

FIG3 is an example diagram of the interrupt processing core process;

FIG4 is a schematic diagram of the state of the dual domain under different interrupt types;

FIG5 is a schematic diagram of a data structure for hard real-time thread scheduling;

FIG6 is a schematic diagram showing the association between the implemented hard real-time domain thread structure and the Linux domain;

FIG7 is a schematic diagram of a hard real-time drive framework;

FIG8 is a schematic diagram of providing a general API independent of the underlying system in an embodiment;

FIG9 is a schematic diagram of implementing scheduling using a priority array;

FIG. 10 is a schematic diagram of implementing scheduling using a FIFO queue method.

DETAILED DESCRIPTION

The specific implementation modes of the present invention are described below so that those skilled in the art can understand the present invention. However, it should be clear that the present invention is not limited to the scope of the specific implementation modes. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention as defined and determined by the attached claims, these changes are obvious, and all inventions and creations utilizing the concept of the present invention are protected.

As shown in FIG. 1 and FIG. 2 , the embedded hybrid kernel operation method supporting hard real-time includes the following steps:

S1. Define a high-priority processing stage through the interrupt pipeline so that the interrupt handler registered in the hard real-time domain is run after receiving the interrupt request (IRQ);

S2, judging whether the current interrupt request is a hard real-time domain interrupt through the interrupt processing program of the hard real-time domain, if so, proceeding to step S3; otherwise, proceeding to step S4;

S3, making the hard real-time domain and the Linux domain both in the interrupt disabled state, processing the hard real-time domain interrupt, and proceeding to step S5;

S4, handing over the current interrupt request to the Linux domain interrupt handler for processing, and making the Linux domain enter the interrupt disabled state, and the hard real-time domain maintains a normal state until the processing of the current interrupt request is completed;

S5. Create a data structure for hard real-time thread scheduling, save key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system;

S6. Configure the scheduling strategy, create and initialize the hard real-time scheduling related data structure, implement task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution;

S7. Schedule hard real-time threads based on the scheduling strategy.

The embedded hybrid kernel operating system supporting hard real-time includes a hard real-time interrupt management module, a hard real-time task processing module, a hard real-time application support module, a hard real-time driver support module, a Linux domain, and a hard real-time domain expanded on the basis of the Linux kernel; wherein the priority of the hard real-time domain is higher than that of the Linux domain;

The core of the hard real-time interrupt management module is to use the interrupt pipe method to realize the division and transfer of interrupt processing between the hard real-time domain and the Linux domain. Specifically, the hard real-time interrupt management module is used to define a high-priority processing stage through the interrupt pipe, so that the interrupt handler registered to the hard real-time domain is run after receiving an interrupt request; the hard real-time domain interrupt handler determines whether the current interrupt request is a hard real-time domain interrupt, and if so, the hard real-time domain and the Linux domain are both in the interrupt disabled state to process the hard real-time domain interrupt; otherwise, the current interrupt request is handed over to the Linux domain interrupt handler for processing, and the Linux domain is put into the interrupt disabled state, while the hard real-time domain remains in a normal state until the processing of the current interrupt request is completed;

The core of the hard real-time task processing module is to achieve the association and decoupling of the hard real-time domain and the Linux domain in task processing by adding new data structures, configuring scheduling strategies, and implementing task domain switching. Specifically, the hard real-time task processing module is used to create data structures for hard real-time thread scheduling, save key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system; configure scheduling strategies, create and initialize hard real-time scheduling-related data structures, implement task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution; schedule hard real-time threads based on scheduling strategies;

The hard real-time application support module is used to encapsulate the existing standard POSIX interface through the alias attribute function in the tool chain, and expose the hard real-time service interface to the user in the form of a dynamic library, so that the user can add the dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks;

The hard real-time driver support module is used to define and implement real-time devices and driver implementations by developing a hard real-time driver framework, so that the same hardware device has corresponding device descriptors in both the hard real-time domain and the Linux domain, so that the same driver device can be switched between the two domains through driver hot switching. At the same time, a general API independent of the underlying system is provided to facilitate users and developers to carry out driver transplantation.

In the specific implementation process, as shown in FIG3 , after the interrupt reaches the system, a lightweight high priority processing stage is implemented through the interrupt pipeline in the interrupt processing core process, which is responsible for processing the interrupt received by the system.

In the specific implementation process, the specific method for determining whether the current interrupt request is a hard real-time domain interrupt is: the current interrupt request is checked in the hard real-time domain through the interrupt handler of the hard real-time domain. If the current interrupt request has a corresponding processing function in the hard real-time domain, the interrupt request is determined to be a hard real-time domain interrupt; otherwise, the interrupt request is determined to be a Linux domain interrupt.

In the specific implementation process, the interrupt pipeline in the Linux domain introduces virtual interrupts to replace the native Linux kernel interrupts. The interrupt operation on the hardware, that is, controlling the local CPU switch interrupt by operating the hardware register, is controlled by the hard real-time domain implementation interface.

As shown in Figure 4, if it is determined that the IRQ is a hard real-time domain interrupt, the entry of the virtual interrupt of the Linux domain is shielded by modifying the corresponding flag bit, and the Linux domain enters the interrupt disabled state. The interrupt of the hard real-time domain modifies the flag bit through the hard real-time domain interface, so that the hard real-time domain enters the interrupt disabled state. If it is determined that the IRQ is a Linux domain interrupt, the entry of the virtual interrupt of the Linux domain is shielded by modifying the corresponding flag bit, and the Linux domain enters the interrupt disabled state. The hard real-time domain remains in a normal state to receive external interrupts.

When the Linux domain enters the interrupt disabled state and the hard real-time domain remains in the normal state, the external interrupt signal can still be delivered to the CPU and interrupted and preempted by the interrupt handler registered by the hard real-time domain.

In the specific implementation process, as shown in FIG5 , the data structure of the hard real-time thread scheduling includes the struct hrt_arch_tcb tcb field, the struct hrt_sched *sched field, and the struct hrt_class *sched_class field;

struct hrt_arch_tcb tcb field, used to store architecture related information;

The struct hrt_sched *sched field is used to store information related to hard real-time scheduling;

The struct hrt_class *sched_class field is used to store information related to hard real-time threads.

As shown in FIG6 , through the implementation of this data structure, the system completes the decoupling of the scheduling of the Linux domain and the hard real-time domain in their respective domains, reducing the potential cross-risk of the system.

In the specific implementation process, the specific method of configuring the scheduling strategy is: the user selects different scheduling strategies through macro configuration according to their own business conditions, that is, through macro configuration, the scheduling strategy is selected as a priority array method or a FIFO method.

In the specific implementation process, the specific methods for creating and initializing hard real-time scheduling related data structures, implementing task domain switching, driving hot switching, and switching from non-real-time domain to real-time domain execution are as follows:

Create a Linux domain thread, recorded as a shadow thread (host thread);

Create and initialize hard real-time scheduling related data structures;

In the native Linux main scheduling interface, add a hijacking operation to set the shadow thread as the hijacking thread of the current CPU;

Trigger a Linux standard schedule (i.e. execute the process of __schedule()-->context_switch()), switch to the end of the next task, call the domain switching process, and complete the switch of the shadow thread from the non-real-time domain to the real-time domain;

Through the hard real-time driver in the hard real-time driver framework, when the task domain is switched, the driver hot switch is completed by referencing the device file descriptor in the hard real-time domain in the hard real-time thread, and the driver is switched from the Linux domain to the hard real-time domain.

The hard real-time domain thread structure is added to the ready queue of the hard real-time scheduler, waiting for the hard real-time scheduler to schedule and run (i.e., schedule the hard real-time thread based on the scheduling policy) until the CPU is abandoned or the hard real-time domain is exited; if the CPU is abandoned or the hard real-time domain is exited, the remaining part of the process that triggers a Linux standard schedule (i.e., returns to the previous __schedule() process) is not completed. The system will run in the Linux domain until the next time the thread calls the "hard real-time upgrade" interface function again to upgrade to the hard real-time domain again.

As shown in FIG7 , the hard real-time driver framework includes predefined real-time class devices and driver implementations, a hard real-time driver programming interface, and a hard real-time driver application interface;

Predefined real-time devices and driver implementations include predefined protocol devices and named devices, such as real-time UART, real-time SPI, real-time GPIO, real-time CAN, and real-time NET, which are commonly used in embedded scenarios. All message-oriented devices are protocol devices, and the rest are named devices. Applications operate protocol devices through posix sockets.

Hard real-time driver programming interface, used to provide clock services, task management services, synchronization services, interrupt management services, non-real-time signal services and other general services (including real-time memory allocation services, user-mode memory access services, real-time kernel console output services and exception checking mechanism services);

The hard real-time driver application interface is oriented to kernel-mode applications and user-mode applications, and is used to provide interface support for kernel-mode applications and user-mode applications that use the hard real-time driver framework.

In addition, as shown in Figure 8, the hard real-time driver framework provides a common API that is independent of the underlying system, making it easier for users and developers to carry out driver transplantation work. Specifically, it refers to two aspects: first, the hard real-time driver application interface is abstractly encapsulated again to form a encapsulation library, which is provided to the application program; second, the hard real-time hardware driver is abstractly encapsulated again to form a hardware abstraction layer, which is provided to developers and users. The hardware abstraction layer can encapsulate the underlying driver code into different interfaces multiple times, thereby realizing code reuse, which is suitable for drivers that require protocol stack cooperation.

In the specific implementation process, the specific method of exiting the hard real-time domain is:

Call the suspend function of the hard real-time domain and set a degradation flag for the hard real-time thread structure;

Enter the main scheduling function of the hard real-time domain, and downgrade the current operation domain from real-time to non-real-time at the entrance of the main scheduling function;

Take out the highest priority ready hard real-time task from the ready queue to replace itself; if there is only hard real-time IDLE task in the current ready queue, return to the previously preempted Linux domain task;

After the hard real-time thread is ready, it is scheduled using the priority array or FIFO queue method according to the macro configuration. As shown in Figure 9, the specific method of using the priority array is:

1) Implement two key data structures, namely priority bitmap and priority array, both of which are located in the ready queue;

2) The priority array is used to record which priority segment in the hard real-time system has ready tasks. If there are any, the corresponding bit is 1, otherwise it is 0;

3) Using the priority bitmap, through the bitmap algorithm, using the instruction set, find the priority array index with the highest priority in the priority array where there is a ready task;

4) According to the array index, find the queue head of the queue of the corresponding priority from the priority array;

5) Add or remove tasks from the queue.

As shown in FIG10 , the specific method of scheduling hard real-time threads using the FIFO queue method is as follows:

1) All hard real-time thread structures on a CPU are organized in a linked list. All hard real-time threads on the linked list are connected in a FIFO organization from low priority to high priority with the same priority.

2) Each time a hard real-time thread is added to the linked list, it is traversed from the tail (high priority) of the linked list to the head of the linked list, and when a thread with a priority less than or equal to the current hard real-time priority is found, it is inserted into the linked list.

In the specific implementation process, the function of the alias attribute in the tool chain is used to encapsulate the existing standard POSIX interface, and the hard real-time service interface is exposed to the user in the form of a dynamic library. The user can add this dynamic library in the compilation stage to achieve the conversion from ordinary Linux tasks to hard real-time domain tasks. Specifically, the dynamic library is implemented through the function encapsulation of the alias attribute, so that the user only needs to link the dynamic library in the compilation stage to compile the task into a hard real-time domain task. This implementation method enables business developers who want to use different systems when running user-mode businesses in different environments only to maintain a set of business codes, and to achieve their demands by making fine adjustments in the compilation project for different operating environments during compilation.

In one embodiment of the present invention, the specific process of processing real-time tasks in a real-time optimized Linux system is as follows:

1) After receiving the IRQ hardware interrupt, the system enters the interrupt processing process and enters the interrupt disabled state;

2) After completing the interrupt processing, the system returns to the process of being able to normally receive external hardware interrupts;

3) Set the system scheduling strategy and process priority. The system scheduling strategy includes time-sharing scheduling strategy, first-come-first-served and time-slice round-robin real-time scheduling strategy. The priority of real-time process is 0-99, and the priority of ordinary process is 100-139;

4) Schedule tasks according to system scheduling strategy and process priority;

5) When using the standard POSIX interface for application development, you need to set the application priority and the system scheduling policy before running the application.

Comparing this process with the present invention, it can be seen that the following differences are included:

①. Differences between IRQ processing design and implementation:

The prior art processes IRQ by disabling interrupts. The present invention realizes the division and transfer of hard real-time domain IRQ and Linux domain IRQ in interrupt processing through interrupt pipeline, virtual interrupt and new interface of hard real-time domain. Linux domain IRQ will not affect the processing of hard real-time domain IRQ. If there is hard real-time domain IRQ, the whole system enters the interrupt disabled state.

② Differences between real-time task scheduling design and implementation:

The scheduling strategies of the prior art include time-sharing scheduling strategies, first-come-first-served and time-slice rotating real-time scheduling strategies, where the priority of real-time processes is 0-99, and the priority of ordinary processes is 100-139. The system schedules tasks according to the scheduling strategies and process priorities currently set by the system. The present invention adds a data structure in scheduling to specifically represent hard real-time threads. This structure stores key information related to hard real-time scheduling and dual domains, and is also associated with the thread data structure of the Linux domain in the data structure, so that hard real-time threads and ordinary Linux threads are separated and have a one-to-one correspondence; in terms of specific scheduling methods, hard real-time scheduling implements two different organizational methods, including priority arrays and FIFO queue methods. Users can choose different scheduling strategies through macro configuration selection according to their own business conditions.

③. Differences in real-time application development methods:

The prior art uses the standard POSIX interface for application development, which requires setting the application priority and setting the system scheduling strategy before running the application. The present invention uses the alias attribute function in the tool chain to encapsulate the existing standard POSIX interface and expose the hard real-time service interface to the user in the form of a dynamic library. The user can add this dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks.

④. Driver support differences:

The existing technology supports non-hard real-time character devices, block devices and network interfaces, has no unified driver framework, and the development follows the development requirements of the kernel module. The present invention implements a hard real-time driver framework, defines and implements real-time devices and driver implementations, including protocol devices and name devices. Through the above definition and implementation, the same hardware device has corresponding device descriptors in the hard real-time domain and the Linux domain, and hot switching of drivers in the dual domains is achieved by referencing device file descriptors in different domains. At the same time, the hard real-time driver support module provides a general API independent of the underlying system, which is convenient for users and developers to carry out driver transplantation.

It can be seen that the differences between the present invention and the above-mentioned prior art include but are not limited to the processing process for IRQ, the scheduling process for real-time threads, and the developer's use of real-time interfaces. The present invention proposes to use interrupt pipes to realize the separation of hard real-time domain IRQ and Linux domain IRQ, determine the IRQ interrupt type, interrupt processing, create hard real-time thread data structure of hard real-time domain, initialize hard real-time scheduling related data structure and switch to real-time domain execution, perform real-time thread scheduling, and implement application development. These steps realize the expansion of the functions of Linux embedded operating system in the hard real-time field, realize the high real-time and high stability operation of hard real-time programs under embedded hybrid kernel operating system, improve the versatility of embedded hybrid kernel operating system in hard real-time scenarios, avoid the compatibility issues of existing real-time operating system with Linux ecology, reduce the pressure on developers to migrate original applications to embedded hybrid kernel operating system supporting hard real-time, and also reduce the difficulty and complexity of developers using real-time interface to develop hard real-time programs.

In summary, the present invention retains the ecological friendliness of the native Linux system, and can achieve compatibility with existing Linux applications at all levels, providing developers with a good development ecology and facilitating the migration of Linux applications; the present invention can achieve the delay determinism of interrupts and scheduling in hard real-time scenarios, and the system can be widely used in embedded hard real-time scenarios, promoting the development of the domestic embedded field; the present invention reduces the complexity of deployment of embedded systems that support hard real-time, and solves the problem of difficult deployment of embedded systems suitable for hard real-time scenarios; the present invention reduces the storage complexity and difficulty in the development of systems and applications at all levels, providing convenience for developers, operators and users.

Claims (10)

1. A method for operating an embedded hybrid kernel supporting hard real-time, characterized in that it comprises the following steps: S1. Define a high-priority processing stage through the interrupt pipeline so that the interrupt handler registered in the hard real-time domain is run after receiving the interrupt request; S2, judging whether the current interrupt request is a hard real-time domain interrupt through the interrupt processing program of the hard real-time domain, if so, proceeding to step S3; otherwise, proceeding to step S4; S3, making the hard real-time domain and the Linux domain both in the interrupt disabled state, processing the hard real-time domain interrupt, and proceeding to step S5; S4, handing over the current interrupt request to the Linux domain interrupt handler for processing, and making the Linux domain enter the interrupt disabled state, and the hard real-time domain maintains a normal state until the processing of the current interrupt request is completed; S5. Create a data structure for hard real-time thread scheduling, save key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system; S6. Configure the scheduling strategy, create and initialize the hard real-time scheduling related data structure, implement task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution; S7. Schedule hard real-time threads based on scheduling policies. 2. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 1 is characterized in that the specific manner of determining whether the current interrupt request is a hard real-time domain interrupt in step S2 is as follows: the current interrupt request is checked in the hard real-time domain by an interrupt handler in the hard real-time domain; if the current interrupt request has a corresponding processing function in the hard real-time domain, the interrupt request is determined to be a hard real-time domain interrupt; otherwise, the interrupt request is determined to be a Linux domain interrupt. 3. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 1, characterized in that the specific methods for making the hard real-time domain and the Linux domain in the interrupt disabled state in step S3 are respectively: Introduce virtual interrupts to replace native Linux kernel interrupts. Modify the virtual interrupt flag to enable virtual interrupts in the Linux domain, and the Linux domain enters the interrupt disabled state. By modifying the hard real-time domain interface flag bit, the hard real-time domain enters the interrupt disabled state. 4. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 1, characterized in that the data structure of the hard real-time thread scheduling in step S5 includes a struct hrt_arch_tcb tcb field, a struct hrt_sched *sched field, and a struct hrt_class *sched_class field; struct hrt_arch_tcb tcb field, used to store architecture related information; The struct hrt_sched *sched field is used to store information related to hard real-time scheduling; The struct hrt_class *sched_class field is used to store information related to hard real-time threads. 5. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 1, characterized in that the specific method for creating and initializing hard real-time scheduling related data structures in step S6, realizing task domain switching, driving hot switching, and switching from a non-real-time domain to a real-time domain for execution is: Create a Linux domain thread, recorded as a shadow thread; Create and initialize hard real-time scheduling related data structures; In the native Linux main scheduling interface, add a hijacking operation to set the shadow thread as the hijacking thread of the current CPU; Trigger a Linux standard schedule, switch to the tail of the next task, call the domain switching process, and complete the switch of the shadow thread from the non-real-time domain to the real-time domain; Through the hard real-time driver in the hard real-time driver framework, when the task domain is switched, the driver hot switch is completed by referencing the device file descriptor in the hard real-time domain in the hard real-time thread, and the driver is switched from the Linux domain to the hard real-time domain. The hard real-time domain thread structure is added to the ready queue of the hard real-time scheduler, waiting for the hard real-time scheduler to schedule and run until the CPU is abandoned or the hard real-time domain is exited; if the CPU is abandoned or the hard real-time domain is exited, the remaining part of the process that triggers a Linux standard scheduling is returned and not completed. 6. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 5, characterized in that the hard real-time driver framework includes predefined real-time class devices and driver implementations, hard real-time driver programming interfaces, and hard real-time driver application interfaces; The predefined real-time devices and driver implementations include predefined protocol devices and name devices; all message-oriented devices are protocol devices, and the rest are name devices; applications operate protocol devices through POSIX sockets; Hard real-time driver programming interface, used to provide clock services, task management services, synchronization services, interrupt management services, non-real-time signal services, real-time memory allocation services, user-mode memory access services, real-time kernel console output services, and exception checking mechanism services; The hard real-time driver application interface is oriented to kernel-mode applications and user-mode applications, and is used to provide interface support for kernel-mode applications and user-mode applications that use the hard real-time driver framework. 7. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 5, wherein the specific method for exiting the hard real-time domain is: Call the suspend function of the hard real-time domain and set a degradation flag for the hard real-time thread structure; Enter the main scheduling function of the hard real-time domain, and downgrade the current operation domain from real-time to non-real-time at the entrance of the main scheduling function; Take out the highest priority ready hard real-time task from the ready queue to replace itself; if there is only hard real-time IDLE task in the current ready queue, return to the previously preempted Linux domain task. 8. The method for operating an embedded hybrid kernel supporting hard real-time according to claim 1 is characterized in that the existing standard POSIX interface is encapsulated through the function of the alias attribute in the tool chain, and the hard real-time service interface is exposed to the user in the form of a dynamic library, so that the user can add the dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks. 9. An embedded hybrid kernel operating system supporting hard real-time, characterized in that it comprises a hard real-time interrupt management module, a hard real-time task processing module, a hard real-time driver support module, a Linux domain, and a hard real-time domain expanded on the basis of the Linux kernel; wherein the priority of the hard real-time domain is higher than that of the Linux domain; The hard real-time interrupt management module is used to define a high-priority processing stage through the interrupt pipeline, so that the interrupt handler registered in the hard real-time domain is run after receiving the interrupt request; the interrupt handler of the hard real-time domain determines whether the current interrupt request is a hard real-time domain interrupt, and if so, the hard real-time domain and the Linux domain are both in the interrupt disabled state to process the hard real-time domain interrupt; otherwise, the current interrupt request is handed over to the Linux domain interrupt handler for processing, and the Linux domain is put into the interrupt disabled state, and the hard real-time domain remains in a normal state until the processing of the current interrupt request is completed; The hard real-time task processing module is used to create the data structure of hard real-time thread scheduling, save the key information related to hard real-time scheduling and dual domains, and ensure the real-time performance of hard real-time task scheduling without destroying the thread scheduling model on the Linux system; configure the scheduling strategy, create and initialize the data structure related to hard real-time scheduling, realize task domain switching, drive hot switching, and switch from non-real-time domain to real-time domain execution; schedule hard real-time threads based on the scheduling strategy; The hard real-time driver support module is used to define and implement real-time devices and driver implementations by developing a hard real-time driver framework, so that the same hardware device has corresponding device descriptors in both the hard real-time domain and the Linux domain, and the same driver device can be switched between the two domains through driver hot switching. 10. The embedded hybrid kernel operating system supporting hard real-time according to claim 9, characterized in that it also includes: The hard real-time application support module is used to encapsulate the existing standard POSIX interface through the alias attribute function in the tool chain, and expose the hard real-time service interface to the user in the form of a dynamic library, so that the user can add the dynamic library during the compilation stage to realize the conversion from ordinary Linux tasks to hard real-time domain tasks.