Interrupts, shared data and DMA

Interrupts are where the outside world meets the software: an encoder edge, a finished ADC conversion, a CAN frame, a timer reaching its compare value. ROB-200 showed how to configure and enable them. This lesson is about their timing and their hazards in a system with many tasks: how long it takes from a hardware event to the first instruction of its handler, what can make that longer, how to share data between interrupt handlers and tasks without corrupting it, and how direct memory access (DMA) moves data without the processor so that interrupts can be fewer and shorter.

Anatomy of interrupt latency

Interrupt latency is the time from the hardware event to the start of useful work in its handler. Several pieces add up:

• Hardware recognition and synchronization: the peripheral raises its request and the interrupt controller registers it, usually a few clock cycles.
• Completion of the current instruction: most instructions finish in a cycle or two, but some (multi-word loads and stores, divides) take longer or are abandoned and restarted.
• Masking: if interrupts are disabled, or a higher- or equal-priority interrupt is running, the new one waits. This is usually the largest and most variable component.
• Entry overhead: saving registers and fetching the vector. On a Cortex-M3, M4 or M7 the hardware stacks eight registers and starts the handler in a fixed 12 cycles in the best case, plus more if floating-point state must be saved and the lazy stacking feature is off.
• Software preamble: anything the handler does before the time-critical step, such as reading a status register or calling into a driver layer.

The masking term is controlled entirely by software design: the longest time anyone disables interrupts, and the longest handler at the same or higher priority, set the worst-case latency for every interrupt below them. A single driver that disables interrupts for 200 µs to copy a buffer adds 200 µs to the worst-case latency of every interrupt in the system.

Interrupt priorities and nesting

Nested vectored interrupt controllers allow a higher-priority interrupt to preempt a lower-priority handler. Each interrupt's worst-case response time can therefore be analyzed with the same response-time equation used for tasks in lesson 5, treating each interrupt source as a sporadic task with a minimum inter-arrival time. Assign interrupt priorities by deadline: the encoder index pulse that must be captured within 2 µs outranks the UART receive that can wait 80 µs, which outranks the 1 kHz control timer whose work takes 100 µs. All interrupts outrank all RTOS tasks, so total interrupt load directly reduces the processor time available to tasks.

On Cortex-M processors running FreeRTOS, interrupts are split by a configuration value called configMAX_SYSCALL_INTERRUPT_PRIORITY. Interrupts more urgent than this level are never masked by the kernel, so they get the lowest possible latency, but they must not call any RTOS function. Interrupts at or below that level may call the FromISR functions, but the kernel masks them briefly in its own critical sections. Choosing which interrupts sit above the line is a real design decision: put the few truly time-critical, self-contained handlers above it, and everything that needs to wake a task below it.

Writing good interrupt handlers

Short, bounded handlers keep latency low for everyone. A good handler acknowledges the hardware, captures the time-critical data, and either finishes the job (if it is tiny) or hands off to a task. A rule of thumb used in many robot firmware teams is that no handler may run longer than about 10 % of the shortest deadline in the system.

/* ADC-complete interrupt: capture, timestamp, hand off to a task */
void ADC_IRQHandler(void)
{
    BaseType_t woken = pdFALSE;
    uint16_t raw = ADC1->DR;                 /* reading DR clears the flag  */
    uint32_t t   = DWT->CYCCNT;              /* timestamp at the source     */
    spsc_push(&adc_ring, raw, t);            /* lock-free, never blocks     */
    vTaskNotifyGiveFromISR(adc_task, &woken);
    portYIELD_FROM_ISR(woken);               /* switch now if task is higher */
}

Timestamping at the source, inside the interrupt, matters for estimation: the Kalman filters of ROB-310 need to know when a measurement was taken, not when a task got round to processing it. The portYIELD_FROM_ISR call asks the kernel to switch directly to the woken task when the handler exits, if that task has higher priority than the one interrupted, so the hand-off adds only a context switch rather than waiting for the next tick.

Sharing data with interrupts

Data shared between an interrupt handler and a task needs protection just as data shared between tasks does, but mutexes cannot be used because a handler must never block. The options are:

• Disable the relevant interrupt, or all interrupts, around the task's access. This is correct but adds to everyone's latency, so it is only for a few instructions.
• Use variables that the processor reads and writes atomically, such as an aligned 32-bit word on a 32-bit processor, for single values like a counter or a flag.
• Use lock-free structures: single-producer single-consumer ring buffers, double buffers and sequence counters (lesson 6).

The C keyword volatile has a narrow job here. It tells the compiler that a variable may change outside the normal flow of the program, so every access must actually read or write memory instead of using a cached register value. Without it, a loop waiting for an interrupt to set a flag may be optimized into an infinite loop that never re-reads the flag. Volatile does not make an access atomic and does not order accesses on multicore processors; it is necessary but not sufficient. For multi-word data and multicore systems, C11 atomics or explicit memory barriers are needed.

# A single-producer single-consumer ring buffer with power-of-two masking
class Ring:
    def __init__(self, size):
        assert size & (size - 1) == 0, "size must be a power of two"
        self.buf = [None] * size
        self.mask = size - 1
        self.head = 0          # written only by the producer (interrupt)
        self.tail = 0          # written only by the consumer (task)
        self.dropped = 0
    def push(self, item):      # producer side: never blocks
        if self.head - self.tail == len(self.buf):
            self.dropped += 1  # full: count and drop instead of waiting
            return False
        self.buf[self.head & self.mask] = item
        self.head += 1         # publish only after the data is written
        return True
    def pop(self):             # consumer side
        if self.tail == self.head:
            return None
        item = self.buf[self.tail & self.mask]
        self.tail += 1
        return item

r = Ring(8)
for burst in range(3):
    for k in range(5):                 # interrupt delivers 5 samples
        r.push((burst, k))
    got = [r.pop() for k in range(3)]  # task keeps up with only 3
    print("burst", burst, "consumed", got, "backlog", r.head - r.tail)
print("dropped samples:", r.dropped)

burst 0 consumed [(0, 0), (0, 1), (0, 2)] backlog 2
burst 1 consumed [(0, 3), (0, 4), (1, 0)] backlog 4
burst 2 consumed [(1, 1), (1, 2), (1, 3)] backlog 5
dropped samples: 1

Because each index is written by only one side, and the producer updates the head only after the data is in place, the consumer never sees a slot that is half-written. When the consumer cannot keep up, the buffer fills and the producer drops new samples and counts them, rather than blocking inside an interrupt. A non-zero drop counter is a design signal: either the buffer is too small for the worst burst or the consuming task's priority or rate is too low.

Direct memory access

A DMA controller moves data between peripherals and memory without the processor, triggered by the peripheral. Instead of one interrupt per ADC sample or per received byte, the DMA fills a whole buffer and raises a single interrupt when it is half full and again when it is full. This cuts interrupt load dramatically and makes sampling timing independent of software latency, because the hardware timer triggers the ADC and the DMA stores each result as soon as it is ready.

The standard pattern is a circular buffer with half-transfer and transfer-complete interrupts, a form of double buffering: while the DMA fills the second half, software processes the first half, and vice versa. The software deadline is then half a buffer's duration, which is much more forgiving than one sample period.

DMA brings its own hazards. On processors with data caches, such as the Cortex-M7 and application processors, the processor may hold stale copies of a buffer the DMA has just written, or the DMA may read memory before the processor's cached writes reach it. The fixes are to place DMA buffers in non-cacheable memory, or to clean and invalidate the cache over the buffer at the right moments. DMA also competes with the processor for the memory bus, which can stretch execution times, another reason to measure WCET under full load.

Interrupt storms and protection

A faulty sensor, a noisy encoder line or a misconfigured peripheral can fire interrupts far faster than designed, starving every task below. Defensive firmware bounds this: count interrupts per period and disable a source that exceeds its expected rate, filter noisy digital inputs in hardware, and use minimum inter-arrival enforcement for sporadic events so that the response-time analysis of lesson 5 remains valid. An emergency-stop input should be handled by hardware first (lesson 11), with software monitoring, so that an interrupt problem cannot delay a safety stop.