5.4Interrupt handlers & resource management

Interrupts are the core mechanism by which an embedded system reacts to external events in real time, but packing too much processing into an interrupt handler (ISR) stalls other interrupts and normal processing for that duration, harming the responsiveness of the system as a whole. Furthermore, if the ISR and normal processing share the same variable, data can become corrupted depending on timing. This section covers how an ISR should be designed and how to protect shared resources—judgments that determine the reliability of embedded software.

5.4.1ISR design principles (keep short, defer processing)

• An ISR (interrupt service routine) is the processing the CPU executes when an interrupt occurs. While an ISR is running, interrupts at the same or a lower level are masked and cannot be accepted, so the longer an ISR runs, the more other interrupt handling is delayed, degrading the real-time responsiveness of the system as a whole. The principle is: "do only the bare minimum inside the ISR (clearing the interrupt cause, saving critical data, etc.), and defer time-consuming processing to normal (task-level) processing."
• A common deferral implementation pattern is for the ISR to only store received data in a buffer and set a flag or semaphore, while the actual data processing and communication handling are done on the normal task side (main loop or RTOS task). This minimizes interrupt-response delay (interrupt latency) while still allowing time-consuming processing to run.