User interrupt event callback mechanism implementation method

Abstract

The invention discloses a user interrupt event callback mechanism implementation method, which adopts an implementation method of combining user interrupt event callback caused by hardware interrupt and conventional task scheduling, after system hardware interrupt occurs, kernel interrupt processing codes construct a user mode code running environment, and a user mode is switched to run a user event callback function, so that the user interrupt event callback is realized. After the execution of the user event callback function is finished, the system environment before the execution of the user event callback function is recovered through an undefined instruction falling into a kernel; and when all the user callback event functions are executed, falling into the kernel through the undefined instruction again, and recovering an instruction execution stream before the interruption event occurs by utilizing the stack frame information reserved when the interruption is entered. According to the method, an emergency processing mechanism with determined delay is realized, the constructed interrupt event callback function runs in a user space, and the method has the functions of shielding low-priority interrupt and protecting a memory, is low in overhead, simple to implement and easy to adapt to various processors, and has a good application prospect.

Description

Technical Field

[0001] The present invention relates to a method for implementing a user interruption event callback mechanism, belonging to the technical field of embedded real-time scheduling. Background Art

[0002] With the rapid development of the industrial Internet and the Internet of Things, intelligent control has become a trend. Fields such as industrial automation, artificial intelligence, communication, automotive, aerospace, consumer electronics, and intelligent healthcare also rely on embedded systems. The embedded system has entered a period of rapid development, and corresponding changes have occurred in the system software and hardware.

[0003] Nevertheless, the embedded hardware should still be application-centered to meet the system's requirements for functions, reliability, cost, volume, power consumption, etc. The selected embedded microprocessor generally requires the ability to quickly respond to asynchronous events and have a strong memory area protection function.

[0004] In addition, due to application scenario limitations, embedded software is generally small in scale and limited in resources. At the same time, many applications have high real-time and reliability requirements, that is, it is required that the software must respond quickly to external events, and in some cases, it is also required to be deterministic, repeatable, and predictable. The memory area protection function of the application program can prevent system crashes caused by incorrect cross-interference between software modules.

[0005] The embedded system management software needs to be responsible for allocating, recycling, controlling, and coordinating the concurrent activities of all software and hardware resources, and providing the operating environment and interfaces for application programs. It is the basis for the operation of application programs and generally adopts the following several program frameworks: (1) The front-back sequential execution method Add an interrupt foreground processing mechanism to the sequential execution situation, configure a sequential execution background large loop program, and combine it into a program that can respond in real time. The front-back system adds the concept of interrupt on the basis of the polling system. The response to external events is completed in the interrupt, and the processing of events returns to the polling system. The general implementation idea is: by setting a flag variable, and then setting or resetting the flag variable when responding to the interrupt in the foreground to obtain the signal of the event, and then processing the things or data corresponding to the interrupt in the background main loop, and transferring the program flow to the main program.

[0006] (2) The time slice rotation method This design uses a timer to allocate time slices for tasks to be run, and then performs counting and comparison in the timer interrupt service routine. When a certain task reaches the preset time, the task ready flag is set. Subsequently, the main program judges the truth or falsehood of each task's ready flag, and different tasks are executed at different times through time slice rotation. This solution is suitable for scenarios where the real-time requirements of tasks are not very high and periodic operation is required.

[0007] (3) Combination of timer interrupt and task scheduling Adopt the method of combining timer interrupt and task scheduler. By reasonably configuring the timer interrupt, the function of executing specific tasks at regular intervals is realized; while using the task scheduler of RTOS, the processor time is allocated to each task according to certain rules and strategies to ensure that they can be executed according to the predetermined priority and order.

[0008] The above methods have defects to varying degrees, which are specifically as follows: The real-time transaction processing of method (1) is arranged in the interrupt service routine. Generally, in the interrupt context, it works in the system privilege mode. In this program structure, all applications cannot be decoupled into privilege operations and ordinary user operations, resulting in the difficulty of truly playing the role of memory protection. The time slice management of method (2) mainly sets the task execution flag in the timer. However, the actual execution requires the main program to complete the current task before it is possible to execute this task. Its rotation strategy determines that it cannot guarantee the timing accuracy of tasks with high priority. When the program logic complexity increases, the timing error and maintenance difficulty also increase accordingly.

[0009] Method (3) This method executes specific tasks through timer interrupts, but this task runs in the interrupt context and has many limitations and security risks. As a variant of method (3), it is to execute user code completely in the task state. However, since the task has a lower priority in the system, it may still be interrupted, which will affect the real-time performance of the system.

[0010] From the above comparison, it can be seen that there are generally two problems in the existing systems. One is that it is difficult to completely separate the kernel mode and user mode to achieve true memory protection, and the other is the lack of an effective response mechanism for events with extremely high response delay requirements. Therefore, overcoming the above problems has become an issue that needs to be solved currently. Summary of the Invention

[0011] The purpose of the present invention is to provide a method for implementing a user interrupt event callback mechanism, which realizes hard real-time service processing by constructing a user-mode running environment in the hardware interrupt and calling the user-side callback function, and achieves an emergency event processing mechanism with deterministic latency.

[0012] To achieve the above object / To solve the above technical problems, the present invention is implemented by the following technical solutions.

[0013] On the one hand, the present invention provides a method for implementing a user interrupt event callback mechanism, which realizes hard real-time service processing by constructing a user-mode running environment in a hardware interrupt and calling a user-side callback function, including the following steps: The application system responds to a hardware interrupt event triggered by an external event and enters the "exception / interrupt" processing mode. Preserve the current interrupt event stack frame and execute the first half of the emergency transaction code of the hardware interrupt event. The kernel interrupt handling code checks whether a user interrupt event callback function is registered on the data structure of the hardware interrupt event. If so, the kernel sets the interrupt mask register, masks low-priority interrupts, and then exits to the "kernel thread" mode, and sequentially executes preset user callback operations according to the registered user interrupt event callback function until all user interrupt event callback functions are executed. When all user interrupt event callback functions are executed, through the reserved current interrupt event stack frame, the control flow is returned to continue execution after the occurrence point of this interrupt event, and the hardware interrupt event ends. Among them, the preset user callback operations include: constructing a user-mode running environment in a hardware interrupt event and calling a user interrupt event callback function. After the user interrupt event callback function is executed, an exception is caused by executing an undefined instruction to enter the "exception / interrupt" processing mode, and this exception handling code is executed. After saving the execution result of the callback function, it returns to the "kernel thread" mode. Thereafter, the kernel-mode environment before the execution of the user interrupt event callback function is restored in the "kernel thread" mode.

[0014] Further, when all user interrupt event callback functions are executed, the kernel detects whether there is a task scheduling requirement. If there is a task scheduling requirement, first trigger a task scheduling software interrupt. Then, the kernel executes an undefined instruction to cause an undefined instruction exception. In the undefined instruction exception caused by executing the undefined instruction, the interrupt mask register and the privilege control register are restored, and through the reserved interrupt event stack frame, the control flow is returned to the occurrence point of this interrupt event to continue execution. Subsequently, respond to the task scheduling software interrupt and execute task scheduling. If there is no task scheduling requirement, the kernel directly executes an undefined instruction to cause an undefined instruction exception. In the undefined instruction exception caused by executing the undefined instruction, the interrupt mask register and the privilege control register are restored, and through the reserved interrupt event stack frame, the control flow is returned to continue execution after the occurrence point of this interrupt event.

[0015] Further, when the kernel interrupt handling code checks that there is no user interrupt event callback function registered on the data structure of the interrupt event, the kernel checks whether there is a task scheduling requirement; If there is a task scheduling requirement, a task scheduling software interrupt is triggered, and the execution flow is controlled to return to the point where the interrupt event occurred to continue execution through the reserved interrupt event stack frame, and then the task scheduling software interrupt is responded to and task scheduling is executed; If there is no task scheduling requirement, the execution flow is directly controlled to return to continue execution after the point where the interrupt event occurred through the reserved interrupt event stack frame.

[0016] Further, the construction of the user-mode running environment includes: setting the stack pointer and status register required by the user-mode code, setting the MMU / MPU for memory protection, setting the interrupt mask register, setting the privilege switching register, and setting the processor running exception level.

[0017] Further, restoring the kernel-mode environment before the execution of the user interrupt event callback function specifically includes: restoring the kernel-mode stack pointer and status register, restoring the kernel-mode memory protection MMU / MPU settings, restoring the settings of the "interrupt mask register" and "privilege control register", and restoring the processor running mode to the "kernel thread" mode.

[0018] Further, in the "exception / interrupt" handling code entered due to an undefined instruction exception caused by executing an undefined instruction, the instruction address that caused the exception is identified. If the exception address is the instruction address where the user interrupt event callback function returns to the kernel, the processing code for the user interrupt event callback function returning to the kernel is executed; if the exception address is the instruction address at the position where the execution flow is restored after the interrupt event processing, the execution flow is controlled to return to continue execution after the point where the interrupt event occurred through the reserved interrupt event stack frame; otherwise, the regular undefined exception handling is executed.

[0019] Further, an application system running on a microprocessor is built, and at the same time, the data structure and service program required for the user interrupt event callback mechanism, and the "registration / deregistration" system call interface function are built. For application requirements, the user task registers the user interrupt event callback function and sets parameters with a specific kernel interrupt service through the "registration / deregistration" system call interface.

[0020] Further, the kernel divides the interrupt requests that cause kernel services in the application system into a high-priority group and a low-priority group according to real-time requirements. For the transactions in the low-priority group, they run in the task scheduling mode and are scheduled and executed by the task scheduler, while the transactions in the high-priority group run in the user interrupt event callback function.

[0021] Further, ordinary user tasks request kernel services through system call instructions (SysCall), while the undefined instruction is used when the user interrupt event callback function returns to the kernel code after execution. The exception handling priority of the system call instruction (SysCall) is set to the lowest, and it can be interrupted by high-priority events when the system call is executed. The "exception / interrupt" handling priority of the undefined instruction is set to the highest, and the handling code of the undefined instruction cannot be interrupted by other events.

[0022] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: The present invention adopts an implementation method that combines a hardware interrupt user event callback mechanism and a conventional task scheduling. By dividing system events into two priority groups, high and low, according to requirements, the user-state event callback function is executed in the high-priority group interrupt service program, and the conventional task scheduling is triggered in the low-priority group interrupt service handler. The combination of the two realizes low-latency processing of high-priority events. At the same time, low-priority events are based on the priority preemption task scheduling strategy, taking into account both the real-time performance and usability of the system, and realizing the separation of the kernel and user space in a true sense and related memory protection. The user interrupt event callback function of the present invention is executed in the user thread context. The user interrupt event callback function can use an independent stack and an independent memory protection strategy, and its execution is not affected by low-priority interrupts and task scheduling; the delay of the user interrupt event callback function is determined, and the execution jitter is small. The present invention uses an undefined instruction to return to the interrupt point of the original interrupt event, which supports interrupt nesting; the system has high real-time performance, good security, and small software overhead. Description of the Drawings

[0023] Figure 1 is a flowchart of the implementation process of a user event callback mechanism of the present invention; Figure 2 is a schematic diagram of the implementation process of a user event callback mechanism of the present invention; Figure 3 is the stack frame structure based on the ARM CORTEX-M exception stack; Figure 4 is a schematic diagram of the ARM CORTEX-M user event callback processing; Figure 5 is an example code before the ARM CORTEX-M raises an undefined instruction to return an event; Figure 6 is the ARM CORTEX-M code that raises an undefined instruction to return to the kernel state. Detailed Embodiments

[0024] It should be noted that exceptions and interrupts have something in common: both are a mechanism to interrupt the current program execution and enter a specific program to handle events. The two have similar stack frames and processing flows. In a sense, interrupts are a type of exception. The interrupt event described in the present invention mainly refers to a hardware interrupt triggered by an application system requesting a kernel service, including interrupt sources such as timers, peripherals, and GPIO. Therefore, interrupt event stack frame processing and exception stack frame processing adopt similar technical routes.

[0025] The technical solution of the present invention is described in detail below through the accompanying drawings and specific embodiments. It should be understood that the embodiments of the present invention and the specific features in the embodiments are detailed descriptions of the technical solution of the present invention, rather than limitations on the technical solution of the present invention. The embodiments of the present invention and the technical features in the embodiments may be combined with each other unless there is a conflict.

[0026] The term "and / or" is only a description of the association relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " generally indicates that the related objects are in an "or" relationship.

[0027] Example 1 like Figures 1-2 As shown, this embodiment provides a method for implementing a user interruption event callback mechanism, a method for implementing a user interruption event callback mechanism, comprising the following steps: Step (1): Build an embedded system (RTOS) that can run on a microprocessor, in which user-mode tasks request kernel services through system call instructions (SysCall); The embedded system (RTOS) includes task creation, task scheduling management, kernel hardware resource allocation management, i.e. driver, memory protection, exception (interrupt) priority management, kernel state exception service program, related system calls, and user callback function registration / deregistration interface, etc. Step (2): The kernel constructs the relevant data structures and service registration / deregistration interface functions required by the user event callback mechanism, and binds the registration / deregistration interface functions to the system call interface functions; In order to manage all interrupts, the kernel needs to build a lookup table that can be indexed by interrupt number. The lookup table should at least contain fields such as the priority of the interrupt at this level, the interrupt mask control word corresponding to the interrupt at this level, the corresponding kernel handler entry, and a pointer to the corresponding user callback data structure.

[0028] The kernel classifies the interrupt requests that cause kernel services in the application system into two categories according to real-time requirements, namely, the high-priority group and the low-priority group. The registration of user interrupt event callback functions is mainly registered in the high-priority group, which can reduce the complexity of system implementation and execution overhead.

[0029] Step (3): When the user-side runs the user task, according to the system application requirements, the user task registers the user interrupt event callback function and related parameters with a specific kernel interrupt service through the registration interface constructed in step (2), and then waits for a hardware interrupt to occur; Step (4): After the system hardware interrupt event occurs, the kernel retains the current interrupt event stack frame, and the hardware triggers the relevant kernel event handling code. After the kernel finishes processing the first half of the interrupt transaction, it checks whether there is a user interrupt event callback function registered on the data structure of this interrupt. If so, go to step (5) to prepare to execute the user interrupt event callback function; When the kernel interrupt handling code checks that there is no user interrupt event callback function registered on the data structure of this interrupt event, the kernel checks whether there is a task scheduling requirement; If there is a task scheduling requirement, trigger a task scheduling software interrupt, and through the reserved interrupt event stack frame, control the execution flow to return to the point where this interrupt event occurred and continue to execute, and then respond to the task scheduling software interrupt to perform task scheduling; If there is no task scheduling requirement, directly control the execution flow to return to continue execution after the point where this interrupt event occurred through the reserved interrupt event stack frame; Among them: In the high-priority group interrupt handling code, use the user interrupt event callback function to replace the task, and when the high-priority group interrupt exits, it can not trigger task scheduling. In the low-priority group interrupt, trigger a task scheduling software interrupt according to the system application requirements. After the hardware interrupt exits, enter the task scheduling interrupt to perform priority preemptive scheduling.

[0030] The relevant data structures required for the user interrupt event callback function mechanism include the entry address of the user callback function, the parameters bound by the user callback function, the stack space used by the user callback function, and the memory protection (MPU / MMU) entry settings used by the user callback function. When the user task registers an event callback, the kernel first applies for a static data structure, and then links the address pointer of the structure to the pointer field corresponding to this interrupt number in the kernel interrupt lookup table. Subsequently, update the entry address of the user callback function, parameters, the stack pointer of the user callback, and the MPU / MMU settings in the data structure according to the parameters provided by the registration function; when the user cancels the callback function, through the cancellation system call interface, release the pointer field corresponding to this interrupt number in the kernel interrupt lookup table, and at the same time release the corresponding original event callback structure.

[0031] When registering a callback function, the user task needs to specify the user space configuration used by the callback function, namely the starting address, size, access attributes of the user space, as well as the location and size of the stack space. To further improve efficiency, the registration function should construct the corresponding MPU / MMU entries during registration and save them in the user callback data structure. Given that the execution priority of the user event callback is higher than that of ordinary user tasks, the user callback can even directly use the MPU / MMU configuration of the currently registered task during registration, and the user callback function can temporarily borrow the stack of the registered task.

[0032] The MPU / MMU configuration table mentioned above includes several table entries, each of which is used to describe a memory space and its access attributes, including the starting address of the memory segment, the size of the memory segment, the cache attribute of the memory segment, and the access permission (the MMU table entry has an additional virtual address field compared to the MPU table entry). When preparing the environment for the user interrupt event callback function, the kernel code reads the relevant MPU / MMU table entries involved in the address space to be accessed by the event callback function from the data structure of the event callback function registered by the user. If the microprocessor supports the MPU, it uses the memory segment address in the table entry to retrieve the system MPU configuration table, first preserves the existing configuration entry for the corresponding address space, and then replaces the configuration entry for that address. Similarly, if the microprocessor supports the MMU, it uses the virtual memory segment address in the table entry to retrieve the system MMU configuration table, first preserves the existing configuration entry for the corresponding virtual address space, and then replaces the configuration entry for that address.

[0033] Step (5): Save the current interrupt stack frame, configure the interrupt mask register to mask low-priority interrupts, and then exit to the "kernel thread" mode. Step (6): The kernel prepares the environment before executing the user interrupt event callback function, including setting the MPU / MMU memory access table entries required by the user interrupt event callback function, setting the stack pointer, and switching the CPU privilege mode to the "user thread" mode. Subsequently, the user interrupt event callback function is executed in the "user thread" mode, and after execution, it proceeds to step (7). Step (7): After the user interrupt event callback function returns to the kernel code space, it returns to the kernel state exception service management code by executing an undefined instruction. Step (8): In the kernel's undefined instruction exception handling code, identify the address that caused the undefined instruction. If its address corresponds to the address where the user interrupt event callback function returns to the kernel code space, then proceed to step (9) to execute the user interrupt event callback function return kernel processing code; otherwise, execute the normal undefined instruction processing.

[0034] Step (9): In the part of the user interrupt event callback function return in the undefined instruction exception handling code of the kernel, the kernel switches the CPU privilege access control word, saves the execution result of the callback function, then modifies the current undefined exception stack frame information and returns to the "kernel thread" mode; Step (10): The kernel restores the MPU / MMU memory protection configuration items before executing the user interrupt event callback function, checks the user interrupt event callback function registration data structure table under this interrupt. If there are still other user interrupt event callback functions, go to Step (6) to continue preparing to execute the next user interrupt event callback function. Otherwise, go to Step (11); Step (11): The kernel checks whether there is a task scheduling requirement. If there is a task scheduling requirement, it should first trigger a task scheduling software interrupt, and then execute an undefined instruction to cause an undefined exception. In the kernel undefined exception handling code, if it is confirmed that the exception address is the task instruction address in Step (11), execute to restore the interrupt mask register and the privilege control register, and use the interrupt stack frame information reserved in Step (4) to return to the execution flow of the original interrupt to continue executing the second half of the interrupt; If there is no task scheduling requirement, the kernel directly executes an undefined instruction to cause an undefined instruction exception. When the undefined instruction exception caused by executing the undefined instruction enters the "exception / interrupt" handling code, restore the interrupt mask register and the privilege control register, and control the execution flow to return to continue executing after the occurrence point of this interrupt event through the reserved interrupt event stack frame.

[0035] Step (12): After the kernel responds to the software interrupt for task switching, it runs the task scheduler, selects the next running task, and performs a task context switch when exiting the software interrupt to start executing the newly selected task.

[0036] As Figure 3 shown, taking the ARM CORTE-M series microprocessors as an example, a schematic diagram of the basic exception stack frame structure is shown. Although different processors have different exception stack frames and processing flows, they all include the exception return address (PC pointer) and the processor status word (XPSR) when the exception occurs, and the general registers involved in the stack frame are determined by the architecture; the exception stack frame mainly includes general registers, application status words, PC pointers, etc.

[0037] As Figure 4The schematic diagram of ARM CORTEX-M user event callback processing is shown. The interrupt event stack frame (stack frame 1) corresponds to the stack frame at the time when the initial interrupt event occurs. The return address corresponds to the instruction address after the interrupt event, and the program status word (XPSR) corresponds to the application program status word at the time of the interrupt. The interrupt handling kernel thread stack frame (stack frame 2) is used to exit from the kernel interrupt mode to the "kernel thread" mode. The return address corresponds to the entry instruction address of the interrupt handling code in the "kernel thread" mode, and the program status word (XPSR) corresponds to the initial status word of the interrupt handling code in the "kernel thread" mode.

[0038] An interrupt event occurs at time t1. The hardware automatically records the interrupt return address (Return Address), the application program status word (XPSR), and the general-purpose registers R0 - R3, R12, LR to form the interrupt event stack frame (stack frame 1). Subsequently, the processor enters the kernel "exception / interrupt" handling mode to run the first half of the kernel interrupt handling code. At time t2, after executing the first half of the interrupt event code, the interrupt handling kernel thread stack frame (stack frame 2) is constructed, and this stack frame is used to exit the kernel interrupt mode to the "kernel thread" mode. At time t3, it starts to check whether there is a user interrupt event callback function. If the user has not registered an event callback function and there is no task scheduling request at this time, it returns to the original location where the interrupt event occurred and continues to execute. If the kernel discovers that this interrupt has registered a user interrupt event callback function, after preparing the environment for the user interrupt event callback function, it starts to execute the user interrupt event callback function code at time t4. After the execution of the user interrupt event callback function ends, it causes an undefined exception at time t5. In the undefined exception handling code of the kernel, an exception stack frame (stack frame 3) is constructed, and this stack frame is used to return to the kernel. Subsequently, the system environment before the execution of the user interrupt event callback function is restored, including MMU / MPU configuration, stack pointer, privileged access mode, interrupt mask control word, etc.

[0039] After the kernel restores the system environment, it checks whether there are other user event callback requirements. If so, it repeats the previous steps to continue executing the user interrupt event callback function. Otherwise, it causes an undefined exception again at time t7, and in the undefined exception handling code, it copies the interrupt event stack frame (stack frame 1) at the time when the initial interrupt event occurred to construct an exception stack frame (stack frame 4). If there is no task scheduling request at this time, it executes an exception return to control the CPU to return to the code position after the original interrupt event occurred and continue to execute.

[0040] The exception stack frame (stack frame 3) is used to return to the kernel state after the execution of the user callback ends. The return address corresponds to the instruction address where the user event callback returns to the kernel (usually corresponding to the kernel instruction address after the "undefined instruction"). The exception stack frame (stack frame 4) is obtained by copying the interrupt event stack frame (stack frame 1) when the initial interrupt event occurs. The return address corresponds to the instruction address after the interrupt event, and the program status word (XPSR) corresponds to the application program status word when the interrupt occurs.

[0041] Before the kernel prepares to continue the execution flow of the original interrupt event, it should first check whether there is a task scheduling requirement in the current system. If task scheduling is required, it triggers a task scheduling software interrupt, and then schedules the execution of ordinary tasks according to the priority in the task scheduling interrupt service code.

[0042] As Figure 4 shown, the kernel interrupt event handling and the execution of the interrupt exit code in the S13 stage are in the kernel's interrupt context, while the user interrupt event callback function environment preparation stage S34 and the system environment restoration stage S67 after the callback work in the kernel thread context. The user callback return code execution stage S56 and the interrupt event return code execution stage S78 execute in the kernel's undefined exception context; except that the user event callback code executes in the non-privileged user space, the rest of the code executes in the kernel space.

[0043] Figure 4 In the code of the S13 stage as shown, when the user interrupt event callback function registered by the user task is found, taking the ARMCORTEX-M architecture as an example, the following operations are performed at the end of the S13 stage: (1), Save the current interrupt event stack frame (stack frame 1); (2), Construct the interrupt handling kernel thread stack frame (stack frame 2), and set the return address field (Return Address) in the stack frame to the entry of the user callback environment preparation code (attached Figure 3 S34 stage); (3), Modify the LR register field in the stack frame to the kernel event end return interface (attached Figure 4 function entry asm_undef_event_return); (4) Modify the application program status word (XPSR) in the stack frame; Execute the interrupt event return instruction to control the CPU to start executing the user callback environment preparation S34 stage code in the kernel thread context.

[0044] After the execution of the user interruption event callback function returns at stage S45, although the current PC pointer points to the kernel instruction space, the CPU is still operating in the non-privileged user mode at this time, and the stack used is still the user space stack.

[0045] The present invention executes the appended Figure 5 undefined instruction shown at the end of stage S45, and completes the switch from the user thread context to the kernel thread context and the privileged mode by triggering the undefined instruction.

[0046] In the kernel undefined instruction (Undefined Instruction) exception handling code, the address of the triggered undefined instruction is identified. If the undefined instruction address is the instruction address (__undef_to_kernel) for the user callback to return to the kernel as shown above, the undefined exception handling code controls the CPU execution flow to continue execution after the undefined instruction (__kernel_start) after setting the privileged mode of the CPU.

[0047] In the kernel undefined instruction (Undefined Instruction) exception handling code, if it is identified that the undefined instruction address is the interrupt event return instruction address (asm_undef_event_return) shown above, the kernel executes the code in stage S78 of the shown exception handling, constructs an exception return stack frame (stack frame 4) using the stack frame information (stack frame 1) reserved in stage S13, and continues the original execution flow after returning to the original event breakpoint. Otherwise, the kernel transfers to the normal undefined exception instruction handling process.

[0048] The said interrupt event return code is implemented in stage S78 of the kernel undefined exception handling code. This section of code needs to restore the privileged control register, interrupt mask register, and stack pointer before the event occurs. After the exception returns, the execution flow of the microprocessor will return to continue execution at the next instruction address after the event occurs.

[0049] The said user callback return code is in the appended Figure 4 stage S56 shown, in the kernel undefined exception handler segment. By constructing an exception stack frame (stack frame 3), setting its return address (Return Address) to the kernel space address (__kernel_start), modifying the stack pointer (SP) to point to the kernel space, and modifying the application status word (XPSR) and the privileged access control register, it realizes the conversion from the user thread context to the kernel thread context and executes the subsequent code in stage S67.

[0050] When the execution of the user interrupt event callback function is completed and returns to the kernel to execute the code in phase S67, the kernel will extract the MPU / MMU configuration items saved before the execution of the callback function and replace and restore the storage protection configuration table.

[0051] As Figure 5 shown in the example code based on ARM CORTEX-M that returns to the execution point after the interrupt event occurs by triggering an undefined instruction, and the attached Figure 5 shows the code based on ARM CORTEX-M that triggers an undefined instruction to return from user mode to kernel mode, and the attached Figure 6 and the attached Figure 5 are in the same way of triggering an undefined instruction. Although the code shows assembly instructions based on Arm Development Studio, those skilled in the art should know that for different processor architectures and different development environments, although the instruction mnemonics are different, the forms are basically the same, and the attached Figure 5 and the attached Figure 6 are also of reference significance.

[0052] Before the user callback of the present invention is executed, it is necessary to set the MPU / MMU management unit of the microprocessor, load the MPU / MMU configuration table set during the registration of the user interrupt event callback function into the MPU / MMU management unit of the processor, ensure that the user interrupt event callback function can access the preset storage space, and at the same time avoid the user interrupt event callback function from accessing the protected storage space; before the user callback is executed, it is also necessary to set the privilege access control register (such as the Control register of ARM CORTEX-M), ensure that the user interrupt event callback function runs in the normal user mode during execution, set the stack pointer in the user space, save the parameters required by the user callback function to the user stack, then copy the entry address of the callback function to the "function pointer" register, and then execute the function call based on this function pointer to enter the normal user mode and start executing the user interrupt event callback function.

[0053] Regarding the priority change and possible interrupt nesting during the execution of the user interrupt event callback function of the present invention, during the normal code execution process, if a high-priority interrupt occurs, the processor raises the priority by hardware to enter the kernel "exception / interrupt" processing mode to execute the first half of the interrupt code, and remains in the same priority to enter the "kernel thread" mode to process the second half of the interrupt code and execute the user interrupt event callback function.

[0054] During the implementation of the user interruption event callback function execution mechanism, the undefined exception handling code has a higher priority, while the execution priorities of the remaining codes are the same as those of the interrupts that trigger the events. To achieve the above purpose, before the kernel event handling code exits the interrupt and enters the kernel thread context, it first sets the interrupt mask control word of the microprocessor to ensure that low-priority interrupts will not interrupt the execution of the current code, and the interrupt mask control word remains unchanged during the entire execution process of the user event callback code, so that the execution of the user event callback code will not be interrupted by ordinary tasks and low-level interrupts.

[0055] In the method for implementing a user event callback mechanism according to the present invention, transactions with low priority requirements are run in task mode and are scheduled and executed by a task scheduler, while transactions with high priority are run in a user interruption event callback function. The kernel interruption event handling code triggers the user interruption event callback function, and after the callback execution is completed, it returns to the kernel.

[0056] In summary, the present invention implements a user event callback mechanism based on hardware interrupts. The user interruption event callback function runs in user space, can use an independent stack and MPU / MMU memory protection settings, and can avoid interference from low-priority interrupts and tasks throughout the process. At the same time, the user callback service has hard real-time characteristics such as low jitter, low latency, and latency determination. By using the undefined instruction to simulate the high-priority user mode to kernel mode conversion operation, the present invention supports interrupt nesting, and has the advantages of high real-time performance, good security, small overhead, and convenient portability. By comprehensively adopting the implementation method of combining the user event callback mechanism based on hardware interrupts and conventional task scheduling, the system's real-time performance, security, and usability are taken into account, and the separation of the kernel and user space in the true sense is achieved, with good prospects.

[0057] The embodiments of the present invention have been described above in conjunction with the accompanying drawings. However, the present invention is not limited to the above specific embodiments. The above specific embodiments are merely illustrative and not restrictive. Under the inspiration of the present invention, those of ordinary skill in the art can also make many forms without departing from the spirit and scope protected by the claims of the present invention. These all fall within the protection scope of the present invention.

Claims

1. A method for implementing a user interruption event callback mechanism, characterized in that: The hard real-time business processing is realized by constructing a user-mode operating environment in a hardware interrupt and calling a user-side callback function, including the following steps: The application system responds to the hardware interrupt event triggered by the external event and enters the "exception / interrupt" processing mode, and retains the current interrupt event stack frame; The kernel interrupt processing code checks whether a user interrupt event callback function is registered on the data structure of the hardware interrupt event. If so, the kernel sets the interrupt mask register, masks the low-priority interrupt, and then exits to the "kernel thread" mode, and executes the preset user callback operations in sequence according to the registered user interrupt event callback function until all the user interrupt event callback functions are executed; When the user interrupt event callback function is fully executed, the control execution flow returns to the point where the interrupt event occurs through the retained current interrupt event stack frame and continues to execute, and the hardware interrupt event ends; Among them, the preset user callback operation includes: constructing a user state running environment in a hardware interrupt event and calling a user interrupt event callback function. After the user interrupt event callback function is executed, an exception is caused by executing an undefined instruction to enter the "exception / interruption" processing mode, and the exception handling code is executed, and after the execution result of the callback function is transferred, the "kernel thread" mode is returned, and thereafter the kernel state environment before the execution of the user interrupt event callback function is restored in the "kernel thread" mode.

2. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: When all user interrupt event callback functions are executed, the kernel detects whether there is a task scheduling requirement; If there is a task scheduling requirement, the task scheduling software interrupt is triggered first, and then the kernel executes the undefined instruction to cause the undefined instruction exception. The undefined instruction exception caused by the execution of the undefined instruction enters the "exception / interrupt" processing code to restore the interrupt mask register and the privileged control register, and through the reserved interrupt event stack frame, the control execution flow returns to the point where the interrupt event occurs to continue execution, and then responds to the task scheduling soft interrupt to perform task scheduling; If there is no task scheduling requirement, the kernel directly executes the undefined instruction to cause an undefined instruction exception; the undefined instruction exception caused by the execution of the undefined instruction enters the "exception / interrupt" processing code to restore the interrupt mask register and the privileged control register, and through the retained interrupt event stack frame, controls the execution flow to return to the point where the interrupt event occurs and continues execution.

3. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: When the kernel interrupt processing code checks that there is no user interrupt event callback function registered on the data structure of the interrupt event, the kernel checks whether there is a task scheduling requirement; If there is a task scheduling requirement, the task scheduling software interrupt is triggered, and the execution flow is controlled to return to the point where the interrupt event occurs through the reserved interrupt event stack frame to continue execution, and then the task scheduling soft interrupt is responded to to perform task scheduling; If there is no task scheduling requirement, the execution flow is directly controlled to return to the point where the interrupt event occurs through the reserved interrupt event stack frame and continue execution.

4. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: The construction of the user mode operating environment includes: setting the stack pointer and status register required by the user mode code, setting the MMU / MPU required for memory protection, setting the interrupt screen register, setting the privilege switching register and setting the processor operation abnormal level.

5. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: The restoring of the kernel state environment before the execution of the user interrupt event callback function specifically includes: restoring the kernel state stack pointer and status register, restoring the kernel state memory protection MMU / MPU settings, restoring the "interrupt mask register" and "privileged control register" settings, and restoring the processor operation mode to the "kernel thread" mode.

6. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: When the undefined instruction exception caused by executing the undefined instruction enters the "Exception / Interrupt" processing code, the instruction address that caused the exception is identified. If the exception address is the instruction address of the kernel position returned by the user interrupt event callback function, the processing code of the kernel returned by the user interrupt event callback function is executed; If the exception address is the instruction address of the execution flow position before the interruption after the interruption event is processed, the execution flow is controlled to return to the point where the interruption event occurs and continue to execute through the reserved interruption event stack frame; Otherwise normal undefined exception handling is performed.

7. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: Build an application system running on a microprocessor, and build the data structure and service program required for the user interrupt event callback mechanism, and the "registration / deregistration" system call interface function; According to the application requirements of the user task, the user interrupt event callback function is registered and the parameters are set to the specific kernel interrupt service through the "register / unregister" system call interface.

8. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: The kernel divides the interrupt requests of kernel services triggered by the application system into high-priority group and low-priority group according to the real-time requirements. The transactions of the low-priority group run in the scheduled task mode and are scheduled for execution by the task scheduler, while the transactions of the high-priority group run in the user interrupt event callback function.

9. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that: The system call instruction exception handling priority is set to the lowest, while the undefined instruction "exception / interrupt" handling priority is set to the highest.

Images