3.5Interrupts and real-time behavior

Interrupts offer the advantage of reacting immediately when something happens, but they carry a side effect: doing time-consuming work inside the ISR degrades the responsiveness of other interrupts and of the task set as a whole. An embedded designer needs both the design judgment of "what should the ISR do, and what should be handed off to a task" and the analytical skill to estimate the strength of the system's real-time guarantee (how confidently deadlines can be met).

3.5.1Separating the ISR from tasks; deferred processing

• The iron rule is that an ISR (interrupt service routine) should immediately recognize that the interrupt occurred and perform only minimal work (recording a flag, reading a register, requesting a task wake-up), then exit the interrupt promptly. While an ISR runs, interrupts at the same level or below are often blocked (or all interrupts are disabled), so the longer the ISR runs, the more it delays detection and response for other interrupts.
• Time-consuming work (formatting data, complex computation, communication handling) should instead be delegated to deferred processing: the ISR wakes a task via a semaphore or event flag, and the actual work runs in that task's normal context. This minimizes the interrupt-disabled window and also lets the work benefit from priority-based scheduling (not blocking other higher-priority work).

3.5.2Hard real-time and soft real-time

• Hard real-time describes a constraint where missing a deadline even once causes the system to lose its safety or core function (a catastrophic outcome). Examples: airbag deployment control, engine ignition timing. The design must guarantee that it always meets the deadline in the worst case.
• Soft real-time describes a constraint where missing a deadline only degrades quality (a worse user experience) rather than causing a fatal failure. Examples: a dropped video frame, a slight audio delay. A design that statistically meets the deadline "most of the time" is acceptable.

3.5.3Interrupt latency, jitter, and response-time analysis

• Interrupt latency is the time from the hardware-level assertion of an interrupt signal to the execution of the ISR's first instruction. The dominant factor is the length of interrupt-disabled sections (periods during which interrupts are disabled, such as inside another interrupt handler or a critical section).
• Jitter is the degree to which the actual start or completion time of periodically scheduled work varies from its ideal period. Causes include variation in interrupt latency, scheduling contention among priorities, and bus contention with cache misses or DMA. In control systems (e.g., PID control), large jitter degrades control accuracy, so an explicit upper bound on period variation is often stated as a design requirement.
• Response-time analysis (RTA) is a mathematical technique for estimating a task's worst-case response time (its own execution time plus the cumulative interference from interrupts and preemption by every higher-priority task). Comparing this to the deadline gives a precise answer to "does it meet the deadline even in the worst case," providing a stricter test than the rate-monotonic utilization bound.

Suppose a firmware developer is investigating a bug in a system containing motor-control task H (a period T=5ms PID control loop, hard real-time, where meeting the deadline is a safety requirement), where "occasionally H's response is delayed and control becomes erratic." The first suspect is interrupt latency. Investigation reveals that a separate ISR for a communication interface performs the received-data parsing work inside the ISR itself, disabling interrupts for as long as 0.8 ms at worst. This is the main cause of the interrupt latency delaying H's notification by up to 0.8 ms. The fix is to shrink that ISR down to minimal work—"copy the received data to a buffer and set a flag"—and delegate the actual parsing to a lower-priority task as deferred processing, cutting the ISR's execution time from 0.8 ms down to a few microseconds. Next, response-time analysis (RTA) is performed to estimate H's worst-case response time: summing the (now much shorter) interference from higher-priority interrupt handling and from any other task at H's priority or above, using the formula H's worst-case response time = H's own execution time + cumulative interference from higher-priority tasks/interrupts, and confirming this value stays below the T=5ms deadline. If this estimate exceeded the deadline, that would be a critical design flaw for H, which is subject to a hard real-time constraint, requiring a review of interrupt priorities, further simplification of the ISR, or a review of the period/execution time of the interfering tasks themselves. By contrast, the same system's audio-streaming processing (soft real-time) can occasionally exceed T with only a minor audio glitch as the consequence, so it does not need RTA as rigorous as H's—monitoring the statistical delay distribution is enough. The design judgment this section calls for is: distinguish hard from soft real-time by whether missing the deadline is catastrophic or merely a quality degradation, and use RTA to guarantee the worst case for hard real-time tasks.

3.5.4Section summary

• An ISR should be kept to minimal work, delegating the time-consuming real processing to a task as deferred processing
• Hard real-time treats even one missed deadline as catastrophic; soft real-time only suffers a quality degradation
• Interrupt latency is dominated by the length of interrupt-disabled sections; response-time analysis (RTA) precisely guarantees worst-case response time against the deadline