computer science//real-time computing//interrupt

An interrupt is a hardware signal that makes a processor suspend the code it is running, execute a short function written for that event (the **interrupt service routine**, ISR) and then resume where it stopped, and it is how a microcontroller reacts to the outside world within microseconds: a sensor saying a sample is ready, a timer marking the start of a control period, a CAN frame arriving, a motor's encoder ticking. The alternative, polling (checking a flag in a loop), wastes the processor and reacts only as fast as the loop goes round.

An interrupt is a hardware signal that makes a processor suspend the code it is running, execute a short function written for that event (the interrupt service routine, ISR) and then resume where it stopped, and it is how a microcontroller reacts to the outside world within microseconds: a sensor saying a sample is ready, a timer marking the start of a control period, a CAN frame arriving, a motor's encoder ticking. The alternative, polling (checking a flag in a loop), wastes the processor and reacts only as fast as the loop goes round.

The quantity that matters is the interrupt latency, the time from the event to the first instruction of the ISR. On an ARM Cortex-M4 it is 12 clock cycles with zero-wait memory, the core saving registers by itself, so at 168 MHz the handler starts in well under a tenth of a microsecond, and with little variation. On a loaded general-purpose Linux the time until a user process notices the same event can reach milliseconds. That difference is why fast loops live on microcontrollers and why a measurement is timestamped in the ISR that read it, as close to the hardware as possible (time synchronization).

An ISR does the minimum and leaves.

Read the register, stamp the time, put the value in a buffer, raise a flag; the filtering and the control law run in a task. Every cycle spent inside a handler delays every lower-priority interrupt and every task, and it is time that no schedule accounted for.

Interrupts have priorities, and a higher one can preempt a running handler (the nested vectored interrupt controller of the Cortex-M does this in hardware, and chains pending handlers back to back without restoring registers in between, tail-chaining). Priorities are assigned by urgency: the IMU's data-ready line above the telemetry UART.

Interrupts are the main source of jitter. A task's execution time stretches by whatever handlers land in the middle of it, so response-time analysis counts interrupt service as one more high-priority load, and a budget kept at modest utilization leaves room for bursts (worst-case execution time).

They fail in characteristic ways. A shared variable written by an ISR and read by a task without protection tears (half old, half new); an interrupt storm from a noisy input line starves everything else, which a watchdog timer on its own oscillator catches; and an event shorter than a PLC's scan is missed unless an interrupt latches it.

Reading, computing and writing in the same timer interrupt is the classic way to keep a control loop's delay at one computation time (loop delay); larger systems move the work into tasks under a real-time operating system, whose own latencies are bounded and documented.