A method for implementing a user interrupt event callback mechanism

Abstract

The application discloses a user interrupt event callback mechanism implementation method, which adopts an implementation method combining a user interrupt event callback caused by a hardware interrupt and a conventional task scheduling; after system hardware interrupt occurs, kernel interrupt processing code constructs a user state code running environment, switches to the user state to run a user event callback function, and then traps into the kernel through an undefined instruction after the user event callback function execution ends, and restores the system environment before the user event callback function execution; when all user callback event functions are executed, the kernel is trapped again through the undefined instruction, and then the instruction execution flow before the interrupt event occurs is restored by using the stack frame information reserved when entering the interrupt. The application realizes an emergency event processing mechanism with a delayed determination, the interrupt event callback function constructed runs in a user space, has the functions of shielding low-priority interrupts and memory protection, has a small cost, is simple to implement, is easy to adapt to various processors, and has a good application prospect.

Description

Technical Field

[0001] This invention relates to a method for implementing a user interruption event callback mechanism, belonging to the field of embedded real-time scheduling technology. Background Technology

[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, communications, automobiles, aerospace, consumer electronics, and smart healthcare also rely on embedded systems. Embedded systems have ushered in a period of rapid development, and the system software and hardware have also undergone corresponding changes.

[0003] Nevertheless, embedded hardware should still be application-centric, meeting the system's requirements for functionality, reliability, cost, size, and power consumption. The selected embedded microprocessor is generally required to have the ability to respond quickly to asynchronous events and strong memory area protection.

[0004] Furthermore, due to application scenario limitations, embedded software is generally small in size and has limited resources. Many applications also have high real-time and reliability requirements, meaning the software must react quickly to external events, and in some cases, it must be deterministic, repeatable, and predictable. Application memory protection features can prevent erroneous cross-interactions between software modules from causing system crashes.

[0005] Embedded system management software is responsible for allocating, reclaiming, controlling, and coordinating the concurrent activities of all hardware and software resources. It also provides the runtime environment and interfaces for applications, forming the foundation for application execution. It typically employs the following program frameworks: (1) Foreground and background sequential execution method To handle sequential execution, an interrupt foreground handling mechanism is added, and a sequentially executing background loop is configured to combine them into a program that can respond in real time. The foreground and background systems incorporate the concept of interrupts into the polling system. External event responses are handled within interrupts, while event processing still returns to the polling system. The general implementation approach is to set a flag variable, and then set or reset this flag variable when responding to an interrupt in the foreground to acquire the event signal. The corresponding transaction or data is then processed in the background main loop, transferring the program flow to the main program.

[0006] (2) Time slice rotation method This design uses a timer to allocate time slices for the tasks that need to run. Then, the timer interrupt service routine counts and compares the time slices. When a task reaches its preset time, the task is ready. The main program then judges whether the ready flags of each task are true or false. By rotating the time slices, different tasks are executed at different times. This design is suitable for scenarios where the real-time requirements of the tasks are not very high and they need to run periodically.

[0007] (3) Combining timer interrupts and task scheduling By combining timer interrupts and a task scheduler, the function of executing specific tasks at set times can be achieved through proper configuration of timer interrupts. Meanwhile, the task scheduler of the RTOS allocates processor time to each task according to certain rules and strategies, ensuring that they can be executed according to predetermined priorities and order.

[0008] The above methods have varying degrees of drawbacks, as detailed below: The real-time transaction processing in method (1) is arranged in the interrupt service routine, which generally operates in system privilege mode in the interrupt context. In this program structure, all applications cannot be decoupled into privileged operations and ordinary user operations, making it difficult for memory protection to truly play its role. Method (2) Time slice management mainly involves setting task execution flags in the timer. However, the task can only be executed after the main program has finished executing the current task. Its round-robin strategy determines that the timing accuracy of high-priority tasks cannot be guaranteed. As the complexity of the program logic increases, the timing error and maintenance difficulty also increase.

[0009] Method (3) executes a specific task through a timer interrupt, but this task runs in an interrupt context, which has many limitations and security risks. A variation of method (3) is to execute user code entirely in task mode, but since the task has a low priority in the system, it may still be interrupted, which will affect the real-time performance of the system.

[0010] The above comparison reveals two common problems in existing systems: first, it is difficult to completely separate kernel mode and user mode to achieve true storage protection; and second, there is a lack of effective mechanisms to deal with events with extremely high response latency requirements. Therefore, overcoming these problems has become a current issue that needs to be addressed. Summary of the Invention

[0011] The purpose of this invention is to provide a method for implementing a user interrupt event callback mechanism. By constructing a user-mode runtime environment in a hardware interrupt and calling a user-side callback function, hard real-time service processing is achieved, thus realizing an emergency event handling mechanism with a certain delay.

[0012] To achieve the above objectives / to solve the above technical problems, the present invention is implemented using the following technical solution.

[0013] On one hand, this invention provides a method for implementing a user interrupt event callback mechanism, which achieves hard real-time service processing by constructing a user-mode runtime environment in a hardware interrupt and calling a user-side callback function, including the following steps: When an application system responds to a hardware interrupt event triggered by an external event, it enters the "exception / interrupt" handling mode. Preserve the current interrupt event stack frame and execute the first half of the emergency task code for 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, exits to "kernel thread" mode, and executes the preset user callback operations in sequence according to the registered user interrupt event callback functions until all user interrupt event callback functions have been executed. After all user interrupt event callback functions have been executed, the execution flow is returned to the point where the interrupt event occurred by using the preserved current interrupt event stack frame, and then the hardware interrupt event ends. The preset user callback operation includes: constructing a user-mode runtime environment and calling a user interrupt event callback function in a hardware interrupt event; after the user interrupt event callback function is executed, triggering an exception by executing an undefined instruction to enter the "exception / interrupt" handling mode, executing the exception handling code, and returning to the "kernel thread" mode after saving the execution result of the callback function; and then restoring the kernel-mode environment before the execution of the user interrupt event callback function in the "kernel thread" mode.

[0014] Furthermore, after all user interrupt event callback functions have been executed, the kernel checks whether there is a task scheduling requirement; If there is a task scheduling requirement, the task scheduling software interrupt is triggered first. Then, the kernel executes an undefined instruction to cause an undefined instruction exception. In the exception interrupt handling code, the interrupt mask register and privilege control register are restored. The execution flow is returned to the point where the interrupt event occurred through the preserved interrupt event stack frame. Then, the task scheduling software interrupt is responded to and the task scheduling is executed. If there is no task scheduling requirement, the kernel will directly execute an undefined instruction to trigger an undefined instruction exception. When an undefined instruction exception is triggered by the execution of an undefined instruction, the interrupt handling code restores the interrupt mask register and privilege control register, and then uses the preserved interrupt event stack frame to return the execution flow to the point where the interrupt event occurred before continuing execution.

[0015] Furthermore, when the kernel interrupt handling code checks that no user interrupt event callback function is 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 through the reserved interrupt event stack frame to continue execution. Then, the task scheduling software interrupt is responded to and the task scheduling is executed. If there is no task scheduling requirement, the execution flow is directly returned to the point where the interrupt event occurred by using the reserved interrupt event stack frame, and execution continues.

[0016] Furthermore, the construction of the user-mode runtime 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 runtime exception level.

[0017] Furthermore, the restoration of 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 "interrupt mask register" and "privilege control register" settings, and restoring the processor's operating mode to "kernel thread" mode.

[0018] Furthermore, in the "Exception / Interrupt" handling code, which is triggered by an undefined instruction, the address of the instruction that caused the exception is identified. If the exception address is the address of the instruction that the user interrupt event callback function returns to the kernel location, the handling code that the user interrupt event callback function returns to the kernel is executed. If the exception address is the address of the instruction that restores the execution flow position before the interrupt after the interrupt event is handled, the execution flow is controlled to return to the point where the interrupt event occurred and continue execution through the preserved interrupt event stack frame. Otherwise, the normal undefined exception handling is performed.

[0019] Furthermore, an application system running on the microprocessor is constructed, along with the data structures and service programs required for the user interrupt event callback mechanism, and the "register / unregister" system call interface functions. User tasks, based on application requirements, register user interrupt event callback functions and set parameters with specific kernel interrupt services through the "register / unregister" system call interface.

[0020] Furthermore, the kernel categorizes interrupt requests triggered by application systems into high-priority and low-priority groups based on real-time requirements. Transactions in the low-priority group are executed in a scheduled task mode and are scheduled by the task scheduler, while transactions in the high-priority group are executed in user interrupt event callback functions.

[0021] Furthermore, ordinary user tasks request kernel services through system call instructions (SysCall), while the user interrupt event callback function returns to the kernel code using undefined instructions. The exception handling priority of system call instructions (SysCall) is set to the lowest, and the execution of system calls can be interrupted by high-priority events, while the exception / interrupt handling priority of undefined instructions is set to the highest, and the processing code of undefined instructions 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 conventional task scheduling. By dividing system events into two priority groups according to demand, user-mode event callback functions are executed in the interrupt service routine of the high-priority group, and conventional task scheduling is triggered in the interrupt service routine of the low-priority group. The two are used together to achieve low-latency processing of high-priority events. At the same time, low-priority events are based on a priority preemptive task scheduling strategy, which takes into account both system real-time performance and ease of use, and achieves true separation of kernel and user space and related storage protection. The user interrupt event callback function of this invention is executed in the user thread context. The user interrupt event callback function can use an independent stack and independent storage 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. This invention uses an undefined instruction exception to return to the interrupt point of the original interrupt event, which can support interrupt nesting; the system has high real-time performance, good security, and low software overhead. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating the implementation of a user event callback mechanism according to the present invention. Figure 2 This is a schematic diagram illustrating the implementation process of a user event callback mechanism according to the present invention; Figure 3 It is based on the ARM Cortex-M basic exception stack frame structure; Figure 4 This is a schematic diagram of user event callback processing based on ARM Cortex-M. Figure 5 This is sample code before an undefined instruction return event occurs, based on ARM Cortex-M. Figure 6 It is based on ARM Cortex-M triggering an undefined instruction and returning to kernel mode code. Detailed Implementation

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

[0025] The technical solution of the present invention will be described in detail below with reference to 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 thereof. In the absence of conflict, the embodiments of the present invention and the technical features in the embodiments can be combined with each other.

[0026] The term "and / or" simply describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have 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, which includes the following steps: Step (1): Build an embedded system (RTOS) that can run on a microprocessor, where user-mode tasks request kernel services via system call instructions (SysCall); The embedded system (RTOS) includes task creation, task scheduling management, kernel hardware resource allocation management (i.e., drivers), memory protection, exception (interrupt) priority management and kernel-mode exception service routines, related system calls, and user callback function registration / unregistration interfaces, etc. Step (2): The kernel constructs the relevant data structures and service registration / deregistration interface functions required for the user event callback mechanism, and binds the registration / deregistration interface functions to the system call interface functions; 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 point, and a pointer to the corresponding user callback data structure.

[0028] The kernel categorizes interrupt requests triggered by application systems into two groups based on real-time requirements: a high-priority group and a low-priority group. User interrupt event callback functions are primarily registered in the high-priority group, which reduces the complexity of system implementation and execution overhead.

[0029] Step (3): When the user task is running on the user side, according to the system application requirements, the user task registers the user interrupt event callback function and related parameters with the specific kernel interrupt service through the registration interface constructed in step (2), and then waits for the hardware interrupt to occur; Step (4): After a 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 handling the first half of the interrupt transaction, it checks whether a user interrupt event callback function is registered on the interrupt data structure. If so, it proceeds to step (5) to prepare to execute the user interrupt event callback function. When the kernel interrupt handling code checks that no user interrupt event callback function is 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 through the reserved interrupt event stack frame to continue execution. Then, the task scheduling software interrupt is responded to and the task scheduling is executed. If there is no task scheduling requirement, the execution flow is directly returned to the point where the interrupt event occurred by using the reserved interrupt event stack frame and then execution continues. Specifically: In the high-priority group interrupt handling code, the user interrupt event callback function is used to replace the task, and the high-priority group interrupt exit does not trigger task scheduling. In the low-priority group interrupt, the task scheduling software interrupt is triggered according to the system application requirements. After the hardware interrupt exits, the task scheduling interrupt execution priority preemption scheduling is entered.

[0030] The data structures required for the user interrupt event callback function mechanism include the user callback function entry address, the parameters bound to 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 a user task registers an event callback, the kernel first allocates a static data structure, then links the structure's address pointer to the pointer field corresponding to the interrupt number in the kernel interrupt lookup table. Subsequently, it updates the user callback function entry address, parameters, user callback stack pointer, and MPU / MMU settings in the data structure according to the parameters provided by the registration function. When a user unregisters a callback function, it unregisters the system call interface, releases the pointer field corresponding to the interrupt number in the kernel interrupt lookup table, and simultaneously releases the corresponding original event callback structure.

[0031] When registering a callback function, a user task needs to specify the user space configuration used by the callback function, namely the user space starting address, size, access attributes, and stack space location and size. To further improve efficiency, the registration function should construct the corresponding MPU / MMU entry and store it in the user callback data structure during registration. Given that the execution priority of user event callbacks is higher than that of ordinary user tasks, user callbacks 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 comprises several entries, each describing a memory space and its access attributes, including the memory segment's starting address, size, cache attributes, and access permissions (MMU entries include a virtual address field, which is present in addition to MPU entries). When preparing the environment for a user interrupt event callback function, the kernel code reads the relevant MPU / MMU entries related to the address space the user-registered event callback function intends to access from the user's registered event callback function's data structure. If the microprocessor supports an MPU, the system MPU configuration table is retrieved using the memory segment address from the entry; the existing configuration entry for the corresponding address space is retained, and then the configuration entry corresponding to that address is replaced. Similarly, if the microprocessor supports an MMU, the system MMU configuration table is retrieved using the virtual memory segment address from the entry; the existing configuration entry for the corresponding virtual address space is retained, and then the configuration entry corresponding to that address is replaced.

[0033] Step (5): Save the current interrupt stack frame, configure the interrupt mask register to mask low-priority interrupts, and then exit to "kernel thread" mode; Step (6): The kernel sets up the environment preparation before executing the user interrupt event callback function, including setting the MPU / MMU memory access table entry required by the user interrupt event callback function, setting the stack pointer, switching the CPU privilege mode to "user thread" mode, and then executing the user interrupt event callback function in "user thread" mode. After execution, proceed to step (7). Step (7): After the user interrupt event callback function returns to the kernel code space, it returns to the kernel-mode 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 the address corresponds to the address returned to the kernel code space by the user interrupt event callback function, then proceed to step (9) to execute the user interrupt event callback function to return to the kernel handling code; otherwise, execute the normal undefined instruction handling.

[0034] Step (9): In the user interrupt event callback function return part of the kernel's Undefined Instruction exception handling code, 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 "kernel thread" mode; Step (10): The kernel resumes the MPU / MMU memory protection configuration before executing the user interrupt event callback function, checks the user interrupt event callback function registration data structure table under this interrupt, and if there are other user interrupt event callback functions, it goes to step (6) to continue preparing to execute the next user interrupt event callback function; otherwise, it goes to step (11). Step (11): The kernel checks whether there is a task scheduling requirement. If there is a task scheduling requirement, the task scheduling software interrupt should be triggered first, and then an undefined instruction should be executed to cause an undefined exception. If the exception address is confirmed to be the task instruction address in step (11) in the kernel undefined exception handling code, the interrupt mask register and privilege control register should be restored, and the interrupt stack frame information saved in step (4) should be used to return to the original interrupt execution flow to continue the execution of the second half of the interrupt. If there is no task scheduling requirement, the kernel directly executes an undefined instruction to trigger an undefined instruction exception. In the "Exception / Interrupt" handling code, the interrupt mask register and privilege control register are restored, and the execution flow is returned to the point where the interrupt event occurred through the preserved interrupt event stack frame to continue execution.

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

[0036] like Figure 3 The diagram shown uses the ARM Corte-M series microprocessor as an example to illustrate the basic exception stack frame structure. Although different processors have different exception stack frames and processing flows, they all contain the exception return address (PC pointer) and the processor status word (XPSR) when the exception occurs. The general-purpose registers involved in the stack frame are determined by the architecture. The exception stack frame mainly includes general-purpose registers, application status word, PC pointer, etc.

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

[0038] When an interrupt event occurs at time t1, the hardware automatically records the interrupt return address, the application status word (XPSR), and general-purpose registers R0-R3, R12, and LR to form the interrupt event stack frame (stack frame 1). Subsequently, the processor enters the kernel "exception / interrupt" handling mode and runs the first half of the kernel interrupt handling code. After executing the first half of the interrupt event code at time t2, the interrupt handling kernel thread stack frame (stack frame 2) is constructed. This stack frame is used to exit the kernel interrupt mode to the "kernel thread" mode. At time t3, it starts checking 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 interrupt event location to continue execution. If the kernel finds that the interrupt has already registered a user interrupt event callback function, it will complete the environment preparation for the user interrupt event callback function and start executing the user interrupt event callback function code at time t4. After the user interrupt event callback function finishes execution, an undefined exception will be raised at time t5. An exception stack frame (stack frame 3) will be constructed in the kernel's undefined exception handling code, and the kernel will be returned using this stack frame. Subsequently, the system environment before the execution of the user interrupt event callback function will be restored, including MMU / MPU configuration, stack pointer, privileged access mode, interrupt mask control word, etc.

[0039] After restoring the system environment, the kernel 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, an undefined exception is raised again at time t7. The kernel copies the interrupt event stack frame (stack frame 1) from when the initial interrupt event occurred in the undefined exception handling code to construct the exception stack frame (stack frame 4). If there is no task scheduling request at this time, the exception returns, and the CPU is controlled to return to the code position after the interrupt event occurred to continue execution.

[0040] The exception stack frame (stack frame 3) is used to return to kernel mode after the user callback execution is completed. The return address corresponds to the address of the instruction that the user event callback returned to the kernel (usually the address of the kernel instruction after "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 occurred. The return address corresponds to the address of the instruction after the interrupt event, and the program status word (XPSR) corresponds to the application status word when the interrupt occurred.

[0041] Before the kernel is ready to continue the execution flow of the original interrupt event, it should first check whether the current system has a task scheduling requirement. If task scheduling is required, a task scheduling software interrupt is triggered, and then ordinary tasks are scheduled to be executed according to priority in the task scheduling interrupt service code.

[0042] like Figure 4 As shown, the kernel interrupt event handling and interrupt exit code execution in stage S13 are performed in the kernel interrupt context, while the user interrupt event callback function environment preparation stage S34 and the system environment recovery stage after callback S67 are performed in the kernel thread context. The user callback return code execution stage S56 and the interrupt event return code execution stage S78 are performed in the kernel undefined exception context. Except for the user event callback code, which is executed in the non-privileged user space, the rest of the code is executed in the kernel space.

[0043] Figure 4 The user interrupt event callback function registered by the user task is found in the S13 stage code shown. 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 kernel thread stack frame for entering interrupt handling (stack frame 2), and set the return address field in the stack frame to prepare code for the user callback environment (see appendix). Figure 3 (S34 stage) entry; (3) Modify the LR register field in the stack frame to the kernel event end return interface (see appendix). Figure 4 (Function entry point: asm_undef_event_return) (4) Modify the application status word (XPSR) in the stack frame; The interrupt event return instruction is executed, which controls the CPU to begin executing the S34 stage code for user callback environment preparation in the kernel thread context.

[0044] After the user interrupt event callback function returns in the S45 phase, although the current PC pointer points to the kernel instruction space, the CPU is still working in non-privileged user mode and the stack is still the user space stack.

[0045] The final execution of the present invention in stage S45 Figure 5 The undefined instruction shown completes the switch from user thread context to kernel thread context and privileged mode by triggering the undefined instruction.

[0046] In the kernel undefined instruction exception handling code, the address that caused the undefined instruction is identified. If the address of the undefined instruction is the address of the instruction that the user callback returns to the kernel (__undef_to_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 CPU privileged mode.

[0047] In the kernel's undefined instruction exception handling code, if the address of the identified undefined instruction is the interrupt event return instruction address (asm_undef_event_return) shown above, the kernel executes the S78 stage code in the exception handling shown above, uses the stack frame information (stack frame 1) saved in the S13 stage to construct the exception return stack frame (stack frame 4), returns to the original event interrupt point, and continues the original execution flow; otherwise, the kernel switches to the normal undefined exception instruction handling flow.

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

[0049] The user callback return code is in the appendix Figure 4 As shown in stage S56, the kernel is in an undefined exception handler segment. By constructing an exception stack frame (stack frame 3), setting its return address to a kernel space address (__kernel_start), modifying the stack pointer (SP) to point to kernel space, and modifying the application status word (XPSR) and privileged access control register, the kernel is switched from the user thread context to the kernel thread context, and the code in stage S67 is executed.

[0050] When the user interrupt event callback function finishes execution and returns to the kernel to execute the S67 stage code, the kernel will extract the MPU / MMU configuration items saved before the callback function execution and replace them with the restored storage protection configuration table.

[0051] like Figure 5 The example code shown is based on ARM Cortex-M and returns to the execution point after an interrupt event occurs by raising an undefined instruction. Figure 5 This demonstrates code that triggers an undefined instruction to return from user mode to kernel mode based on ARM Cortex-M. (Attached) Figure 6 and attached Figure 5 The methods for triggering undefined instructions are consistent. Although the code demonstrates assembly instructions based on Arm Development Studio, those skilled in the art should know that while the instruction mnemonics differ for different processor architectures and development environments, their forms are essentially the same. Figure 5 and attached Figure 6 It is also of reference value.

[0052] Before executing the user callback, this invention requires configuring the microprocessor's MPU / MMU management unit. The MPU / MMU configuration table set during the registration of the user interrupt event callback function is loaded into the processor's MPU / MMU management unit to ensure that the user interrupt event callback function can access the preset memory space, while also preventing it from accessing protected memory space. Before executing the user callback, a privileged access control register (e.g., the Control register of ARM Cortex-M) also needs to be configured to ensure that the user interrupt event callback function runs in normal user mode. The user space stack pointer is set, the parameters required by the user callback function are saved to the user stack, and then the callback function's entry address is copied to the "function pointer" register. Then, a function call based on this function pointer is executed, entering normal user mode and starting the execution of the user interrupt event callback function.

[0053] This invention relates to the priority changes and possible interrupt nesting during the execution of the user interrupt event callback function. During normal code execution, if a high-priority interrupt occurs, the processor raises the priority through hardware and enters the kernel "exception / interrupt" handling mode to execute the first half of the interrupt code. It then maintains the same priority and enters the "kernel thread" mode to handle the second half of the interrupt code and execute the user interrupt event callback function.

[0054] In the implementation of the user interrupt event callback function execution mechanism, undefined exception handling code has a higher priority, while the execution priority of the remaining code is the same as that of the interrupt that triggered the event. To achieve this, the kernel event handling code sets the microprocessor's interrupt mask control word before exiting the interrupt and returning to the kernel thread context, ensuring that low-priority interrupts do not interrupt the current code execution. Furthermore, the interrupt mask control word remains unchanged throughout the entire execution of the user event callback code, preventing the execution of the user event callback code from being interrupted by ordinary tasks and low-level interrupts.

[0055] The user event callback mechanism implementation method described in this invention runs transactions with low priority in task mode and is scheduled and executed by the task scheduler, while transactions with high priority run in the user interrupt event callback function. The user interrupt event callback function is triggered by the kernel interrupt event handling code and returns to the kernel after the callback is completed.

[0056] In summary, this invention implements a user event callback mechanism based on hardware interrupts. The user interrupt event callback function runs in user space and can utilize independent stacks and MPU / MMU memory protection settings, avoiding interference from low-priority interrupts and tasks throughout the process. Simultaneously, the user callback service exhibits hard real-time characteristics such as low jitter, low latency, and deterministic latency. By utilizing undefined instructions to simulate high-priority user-mode to kernel-mode transitions, this invention supports interrupt nesting, offering advantages such as high real-time performance, good security, low overhead, and easy portability. By comprehensively employing a hardware interrupt-based user event callback mechanism combined with conventional task scheduling, this invention balances system real-time performance, security, and ease of use, achieving true separation of kernel and user space, and shows promising potential.

[0057] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A method for implementing a user interruption event callback mechanism, characterized in that, Hard real-time service processing is achieved by constructing a user-mode runtime environment in a hardware interrupt and calling user-side callback functions, including the following steps: When the application system responds to a hardware interrupt event triggered by an external event, it enters the "exception / interrupt" handling mode and retains the current interrupt event stack frame; 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, exits to "kernel thread" mode, and executes the preset user callback operations in sequence according to the registered user interrupt event callback functions until all user interrupt event callback functions have been executed. After all user interrupt event callback functions have been executed, the execution flow is returned to the point where the interrupt event occurred by using the preserved current interrupt event stack frame, and then the hardware interrupt event ends. The preset user callback operation includes: constructing a user-mode runtime environment and calling a user interrupt event callback function in the event of a hardware interrupt; after the user interrupt event callback function completes execution, triggering an exception by executing an undefined instruction to enter the "exception / interrupt" handling mode, executing exception handling code, and returning to the "kernel thread" mode after saving the execution result of the callback function. Subsequently, in the "kernel thread" mode, the kernel-mode environment before the execution of the user interrupt event callback function is restored. After all user interrupt event callback functions have been executed, the kernel checks whether there is a task scheduling requirement. If there is a task scheduling requirement, the task scheduling software interrupt is triggered first. Then, the kernel executes an undefined instruction to cause an undefined instruction exception. In the "Exception / Interrupt" handling code, the interrupt mask register and privilege control register are restored. The execution flow is returned to the point where the interrupt event occurred through the preserved interrupt event stack frame. Then, the task scheduling software interrupt is responded to and the task scheduling is executed. If there is no task scheduling requirement, the kernel directly executes an undefined instruction to trigger an undefined instruction exception. Upon entering the "Exception / Interrupt" handling code, the interrupt mask register and privilege control register are restored. Then, using the preserved interrupt event stack frame, the execution flow is redirected back to the point where the interrupt event occurred to continue execution. The priority of exception handling for system call instructions is set to the lowest, while the priority of exception / interrupt handling for undefined instructions is set to the highest.

2. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, When the kernel interrupt handling code checks that no user interrupt event callback function is 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 through the reserved interrupt event stack frame to continue execution. Then, the task scheduling software interrupt is responded to and the task scheduling is executed. If there is no task scheduling requirement, the execution flow is directly returned to the point where the interrupt event occurred by using the reserved interrupt event stack frame, and execution continues.

3. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, The construction of the user-mode runtime 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 runtime exception level.

4. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, The process of 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 "interrupt mask register" and "privilege control register" settings, and restoring the processor's operating mode to "kernel thread" mode.

5. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, When an undefined instruction exception is triggered by the execution of an undefined instruction, the "Exception / Interrupt" handling code is entered. The address of the instruction that triggered the exception is identified. If the exception address is the address of the instruction that the user interrupt event callback function returns to the kernel location, the handling code that the user interrupt event callback function returns to the kernel is executed. If the exception address is the address of the instruction that restores the execution flow position before the interrupt after the interrupt event is handled, then the execution flow is controlled to return to the point where the interrupt event occurred and continue execution through the reserved interrupt event stack frame; Otherwise, perform the standard undefined exception handling.

6. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, Build the application system that runs on the microprocessor, and at the same time build the data structures and service programs required for the user interrupt event callback mechanism, as well as the "register / unregister" system call interface functions; Based on the application requirements of the user task, the user interrupt event callback function and set parameters are registered with the specific kernel interrupt service through the "register / unregister" system call interface.

7. The method for implementing the user interruption event callback mechanism according to claim 1, characterized in that, The kernel categorizes interrupt requests triggered by application systems into high-priority and low-priority groups based on real-time requirements. Transactions in the low-priority group are executed in a scheduled task mode and are scheduled by the task scheduler, while transactions in the high-priority group are executed in user interrupt event callback functions.

Images