Polling, Interrupts, and Events

Polling reads a status flag on a schedule, in the main loop (unit 7, lesson 6) or a timer tick. It is simple, predictable and needs no special care with shared data. Its costs are that every check takes time whether or not anything happened, and that an event waits up to one polling period to be noticed. If the peripheral can hold only one event (a single received byte, say), polling must also be faster than the events arrive, or events are lost.

With an interrupt, the peripheral raises a request and the core stops what it is doing, saves its state (unit 6, lesson 4) and runs a handler. Nothing is spent while nothing happens, and the response is within the interrupt’s entry latency. Each event costs the entry, the handler and the exit; the handler’s own work would be needed with polling too, so the real comparison is the entry and exit overhead against the cost of all the checks.

↑ This step uses the figure at the top of the page.

The balance tips with the event rate. Rare events favour interrupts overwhelmingly. At hundreds of thousands of events a second, interrupt overhead eats a large share of the CPU, and a polling loop fast enough not to miss any does too; such data is better buffered in a FIFO or moved by DMA (unit 12).

When there is nothing to do, a Cortex-M core can sleep. WFI (wait for interrupt) stops the core until an enabled interrupt with a priority above the current execution priority becomes pending (even one PRIMASK is masking). WFE (wait for event) stops it until an event: an interrupt, a SEV instruction from another core, or, with the SEVONPEND bit set, any interrupt becoming pending even while it is disabled or masked. A main loop that ends in __WFI() spends idle time asleep instead of spinning, which is the first step to low power (unit 14).

Many chips also route events directly between peripherals: a timer overflow starting an ADC conversion, an ADC result triggering a DMA transfer. No handler runs at all, and there is nothing for software latency to spoil.

A UART at 115 200 baud with 8N1 framing delivers 11 520 bytes per second, one every

If the receiver holds a single byte, polling every 100 µs loses bytes during a continuous stream: the next byte overwrites the previous one before it is read. Polling every 50 µs would work but costs CPU time all the time. An interrupt per byte, with an illustrative 60-cycle cost at 48 MHz, uses 11 520 × 60 / 48 × 10⁶ ≈ 1.4 % of the CPU only while data flows, and responds within its entry latency. At megabaud rates the interrupt load climbs, and DMA becomes the better answer.