Microcontroller Interrupts & Event Handling
An interrupt is a negotiated ownership transfer: hardware records an event, mask and priority logic decide eligibility, the core saves architectural return state, software services and acknowledges the source, and an interrupt return restores the prior execution contract.
An interrupt is not “a function that runs automatically.” It is a hardware and software protocol that transfers control because an eligible event requires service. Correctness depends on the source condition, flag, enable masks, priority, vector, saved state, acknowledgement, and return behavior.
Event, flag, pending state, and vector are different #
- A condition is the physical or peripheral state: receive data present, compare matched, pin level active.
- An event flag records that something happened or is true.
- A mask/enable controls whether that source may request service.
- pending means the interrupt controller has an eligible request awaiting acceptance.
- A vector identifies the entry address or slot selected for the source.
Some flags latch edges; others mirror levels. Some clear on hardware vectoring, some on a data-register access sequence, some by writing one, and some only when the underlying condition disappears. Clearing the wrong object causes lost events or interrupt storms.
Entry and return #
At an instruction boundary allowed by the architecture, the core accepts a source, saves architectural return information, changes interrupt-enable state as defined, and fetches the vector. Software must then preserve every additional register and status value required by its ABI and by interrupted code.
An interrupt return is not necessarily an ordinary subroutine return. It may restore global interrupt semantics or notify priority hardware that service is complete. On MCS-51, RETI has controller significance beyond RET; on AVR, the compiler's ISR prologue/epilogue and RETI preserve the relevant machine state.
Latency is a chain #
Worst-case response time includes:
- event detection and synchronization;
- completion of the current instruction or non-interruptible operation;
- time blocked by global masks or higher-priority handlers;
- vector fetch and hardware entry;
- compiler/assembly prologue;
- execution before the time-critical action.
Average latency is rarely the safety bound. A long critical section, flash operation, disabled clock domain, or higher-priority ISR can dominate the maximum.
Acknowledgement ordering #
For a receive interrupt, the data register may need to be read to remove the condition. For a timer, software may clear a latched flag after recording the count. For a level-sensitive external interrupt, clearing a flag while the pin remains active immediately makes the request pending again.
A robust order is source-specific:
- capture volatile evidence that can be overwritten;
- make the source unable to retrigger incorrectly—drain data, clear the condition, or mask it;
- acknowledge the latched state using the exact documented rule;
- publish minimal work to the main context;
- restore state and return.
ISR design #
Keep the ISR bounded and explicit about ownership. It should usually move data into or out of a small buffer, record a timestamp or error, advance a peripheral state machine, and signal deferred work. Blocking on an event that only lower-priority or masked code can produce creates deadlock.
Shared ISR/main state requires more than volatile. Volatile constrains compiler elision; it does not make a multi-byte access atomic or establish a complete synchronization protocol. Use architecture-appropriate critical sections, atomic primitives, single-producer/single-consumer buffer rules, or snapshot protocols.
Priority and nesting #
Priority answers which eligible source runs first. Nesting answers whether another source can preempt the current ISR. More priority levels can reduce latency for critical events, but they enlarge the set of interleavings and worst-case stack use.
Calculate stack depth from the deepest permitted nesting path, hardware-pushed return state, compiler prologues, called functions, local variables, and any library code. On small MCUs, an interrupt stack overflow usually corrupts ordinary RAM without a fault exception.
Polling versus interrupts #
Polling is often better for a high-rate source when work is continuously available and predictable. Interrupts are useful when events are sparse, response latency matters, or the CPU can sleep. A hybrid pattern enables an interrupt for the first event, then drains a batch by polling before rearming.
Choose by event rate, service cost, latency bound, queue depth, overflow behavior, and energy—not by the claim that interrupts are automatically more efficient.
Debugging evidence #
| Failure | Inspect |
|---|---|
| Never enters ISR | source condition, flag, local enable, global enable, vector table, pin/event route |
| Enters continuously | uncleared level, wrong clear rule, unread data, immediate retrigger |
| Loses events | flag coalescing, insufficient buffer, long masks, wrong ordering, overflow flag |
| Main code corrupts | unsaved register/status, non-atomic shared state, stack overflow |
| Timing occasionally fails | worst-case higher-priority path, instruction boundary, synchronization, clock wake |
Record the raw source flag, mask state, vector identity, reset cause, and timestamp before changing them. Interrupt debugging is evidence preservation under concurrency.