1.3Interrupt mechanisms

An embedded device must react quickly to asynchronous events—a sensor value arriving, a timer expiring, communication data being received—and the mechanism for this is the interrupt. Beyond simply knowing what an interrupt is, the skill of judging how to design priority when multiple interrupts compete simultaneously, and what should and should not be done inside an ISR, determines a system's responsiveness and stability.

1.3.1External and internal interrupts, and the vector table

• An external interrupt is triggered by a factor external to the CPU, such as a voltage change on a GPIO pin, a timer expiring, or a communication module receiving data. An internal interrupt is triggered by the CPU's own instruction execution, such as a divide-by-zero, an access violation, or a system call (a software interrupt); this is also often called an exception.
• The vector table is a table storing, for each interrupt source, the starting address of the corresponding interrupt service routine (ISR). When an interrupt occurs, the CPU looks up the vector table using the interrupt number and jumps directly to the matching ISR, eliminating the need to determine in software each time which interrupt arrived, thereby improving responsiveness.

1.3.2Priority, nested interrupts, and interrupt latency

• Priority determines, when multiple interrupts occur simultaneously or while one is already being handled, which one is serviced first. Nested interrupts is the mechanism by which, if an interrupt of higher priority occurs while an ISR is executing, the current ISR's processing is temporarily suspended, the higher-priority interrupt is serviced first, and control returns to the original ISR afterward. A lower-priority interrupt cannot preempt another interrupt that is already being handled.
• Interrupt latency is the time from when an interrupt source occurs until the ISR's first instruction is actually executed. Factors contributing to this delay include waiting for the currently executing instruction to complete, an interrupt-masked (disabled) state, and preemption by a higher-priority interrupt, and in real-time control, the worst-case value of this latency must be known.

Suppose you are an embedded firmware developer designing a system that handles two kinds of interrupts: a high-frequency interrupt detecting motor rotational position (a 1 ms period), and a data-reception interrupt from a communication module (irregular, low frequency). A colleague proposes, "let's do the received-data validation, conversion, and all subsequent processing together inside the data-reception ISR—the code will be simpler and easier to follow." The problem here is that while this ISR is executing, other interrupts of equal or lower priority (in this case, the motor position detection interrupt) are made to wait. If the data-reception ISR is designed to take several milliseconds, the motor position detection interrupt's handling is delayed during that time, and the real-time requirement of motor control needed every 1 ms breaks down. The appropriate design is to perform only minimal work inside the ISR—clearing the interrupt flag, stashing the received data into a buffer—and delegate validation, conversion, and subsequent processing to a lower-priority task or the main loop. If the motor position detection interrupt and the data-reception interrupt occur at the same time, priorities must be configured so that nested interrupts correctly service the higher-priority motor position detection interrupt first. The judgment that "the ISR still works correctly even if it's long" overlooks the embedded-system-specific side effect that interrupt latency degrades the responsiveness of subsequent higher-priority events.

1.3.3Section summary

• An external interrupt is triggered by a factor outside the CPU; an internal interrupt (exception) is triggered by the CPU's own instruction execution
• The vector table enables a direct jump to the ISR, improving responsiveness. Nested interrupts let only a higher-priority interrupt preempt a lower-priority ISR
• Keeping the ISR to minimal work and delegating heavy processing elsewhere holds down interrupt latency and protects the responsiveness of subsequent interrupts