Interrupts: responding to events

So far, the main loop checks everything by asking repeatedly: is the button pressed, has a byte arrived. This is called polling, and it fails when the loop is busy or the event is short. An interrupt reverses this: the hardware pauses the main loop, runs a function of yours called an interrupt handler or ISR, and then resumes the loop exactly where it stopped.

On Cortex-M, a handler is an ordinary C function with a fixed name that comes from the chip maker's startup file, such as TIM2_IRQHandler or EXTI0_IRQHandler on STM32. It takes no arguments and returns nothing. You enable the interrupt in the peripheral and in the NVIC, the interrupt controller, and from then on the hardware calls the handler.

The main design rule is to keep the handler short. Record what happened, set a flag or put a byte in a buffer, then return. Do the slow work in the main loop. Anything that waits inside a handler, such as a delay or a printf over a slow UART, stalls every interrupt at the same or lower priority, and often the whole system.

A flag that a handler sets and the main loop reads must be declared volatile. Without volatile, the compiler may read the flag once into a register and never read memory again, so the loop waits forever for a value the handler has already changed. Volatile tells the compiler that the value can change outside the normal program flow and must be read from memory every time. It does not make anything atomic; atomicity is a separate topic.