What is the interrupt handling of the embedded MCU?
As we all know, on the one hand, an important reason for the widespread use of MCUs in embedded systems is their timeliness advantages over MPUs and general purpose CPUs. Low-latency peripheral interrupts and interrupt nesting are the biggest guarantees for MCU real-time performance. On the other hand, in the development of embedded system MCU software, with the increasingly complex system functions, multitasking is inevitable regardless of whether or not RTOS is adopted. In the streaking system, in order to get the time-critical task to get the first response, it is often necessary to implement the peripheral interrupt nesting, which belongs to the peripheral-based hardware interrupt nesting. In the RTOS, all the system tasks are assigned. With specific priority, the kernel schedules according to the priority level, which actually implements a set of priority-based software interrupt nesting. The task software nesting in the RTOS uses the kernel tick timer interrupt to continuously query the priority level of each task in the RTOS task ready list to implement task switching, and the peripheral hardware interrupts do not necessarily need to be nested.
Since interrupt nesting is so important for embedded system design, what is interrupt nesting? Before specifically explaining the interrupt nesting, it is necessary to first talk about the interrupt working mechanism and interrupt priority of the embedded MCU:
Engineers who have written bare-bones know that a core CPU can only execute one task/program code/instruction at a time, such as data calculations, and interactive communication with on-chip peripherals. The execution order of the code is written by the user himself, and the CPU fetches, decodes, and executes line by line. The implementation of the product function is in the while(1) loop of the main function (often called the main program), and it is constantly called by other function functions. However, in the actual working environment, many events occur randomly, such as network communication, external IO input and other uncertain events. At this time, the CPU has to put down the work currently being executed, but responds to these emergencies and reads network messages in time. Handle and respond to network communication needs and timely external IO requests. This kind of processing is called interrupt.
Kernel CPU exceptions and various peripheral operations in the embedded MCU can generate interrupts for response and are managed uniformly by the interrupt controller. In this way, the CPU can concentrate on the tasks executed sequentially when the interrupt is not generated, and interrupt the CPU through the interrupt controller only when the interrupt is generated (by generating a high/low signal to the CPU, this process is called interrupt). Request), if the CPU global interrupt is enabled at this time, the CPU will combine the interrupt vector table and interrupt priority configuration, according to the interrupt priority level (if multiple peripheral interrupts occur at the same time), take out from the interrupt vector table The ISR address of the highest priority interrupt service routine pushes the current CPU runtime environment onto the stack and then jumps to the interrupt ISR address. If the CPU global interrupt is closed, the current interrupt request is ignored.
The interrupt/exception handling flowchart of the S12 core CPU is as follows:
Interrupt response - interrupt ISR and interrupt real-time
When an interrupt is generated, the interrupt controller requests the core CPU for an interrupt response.
The typical response is that the CPU runs the interrupt ISR that was prepared in advance.
If you want to know more, our website has product specifications for MCU, you can go to ALLICDATA ELECTRONICS LIMITED to get more information