Interrupt-Driven Firmware Design: Managing Multiple Peripherals Simultaneously

Interrupt-Driven Firmware Design: Managing Multiple Peripherals Simultaneously

By Vaishak C

How to orchestrate complex embedded systems without breaking a sweat

Picture this: your embedded system needs to capture high-speed camera data, communicate over multiple protocols, monitor sensors, and respond to user input, all simultaneously, all in real time. That's the world of modern embedded firmware, where a single microcontroller juggles dozens of tasks at once.

Most firmware engineers start with simple polling loops, but as system complexity grows, this approach crumbles under timing constraints and missed events. The fix is interrupt-driven architecture with intelligent priority management, a design philosophy that turns chaotic multi-peripheral systems into something closer to an orchestrated system, handling six-plus peripherals simultaneously without the overhead of a full RTOS.

The challenge: peripheral chaos

Consider a typical camera control system: a high-speed camera interface generating interrupts every 16ms for 60fps capture, CAN bus communication demanding sub-millisecond response, multiple I2C sensors needing periodic polling and threshold monitoring, UART interfaces needing immediate attention for command processing, SPI flash operations that block other activity during write cycles, and system timers maintaining real-time scheduling.

The naive approach, handling everything in a main loop, fails badly. Critical events get missed, timing becomes unpredictable, and the system gets unreliable under load. Polling-based systems suffer from unpredictable latency (often 1 to 100ms response times), missed events during blocking operations, wasted CPU on unnecessary checks, and no way to prioritize critical tasks. Full RTOS solutions solve some of this but introduce their own costs: real memory overhead, context switching delays, more complexity than the project may need, and licensing or certification concerns.

Intelligent interrupt architecture

The key is a lightweight, priority-driven interrupt system giving RTOS-like capability without the overhead, built on four principles. Priority-based interrupt hierarchy makes sure critical peripherals get higher priority so time-sensitive operations never wait. Minimal context switching keeps ISRs lean, deferring heavy processing to the main loop with smart queuing. Deterministic timing means designing for worst-case scenarios with measurable, predictable response times. And graceful degradation means the system keeps functioning even when overwhelmed, prioritizing safety-critical operations first.

Implementation strategy

Step 1: interrupt priority planning. Map peripherals to priority levels based on timing requirements:

// Priority Level 0 (Highest) - Critical Safety
#define WATCHDOG_IRQ_PRIORITY     0
#define FAULT_HANDLER_PRIORITY    0

// Priority Level 1 - Time-Critical Data
#define CAMERA_DMA_PRIORITY       1
#define CAN_RX_PRIORITY          1

// Priority Level 2 - Communication
#define UART_PRIORITY            2
#define I2C_PRIORITY             2

// Priority Level 3 - Background
#define TIMER_TICK_PRIORITY      3
#define SPI_FLASH_PRIORITY       3

Step 2: lean ISR design. Keep ISRs fast and focused, notify and defer rather than process inline:

// Good: Fast ISR with deferred processing
void CAMERA_DMA_IRQHandler(void) {
    if (DMA_GetITStatus(DMA_STREAM, DMA_IT_TCIF)) {
        frame_ready_flag = true;
        DMA_ClearITPendingBit(DMA_STREAM, DMA_IT_TCIF);
        // Defer image processing to main loop
    }
}

// Bad: Heavy processing in ISR
void CAMERA_DMA_IRQHandler(void) {
    // Don't do this - blocks other interrupts
    process_image_data();
    apply_filters();
    compress_frame();
}

Step 3: event queue system. A lightweight task queue handles deferred processing safely across interrupt and main-loop contexts:

typedef struct {
    uint8_t peripheral_id;
    uint16_t event_type;
    void* data_ptr;
    uint32_t timestamp;
} event_t;

#define MAX_EVENTS 32
static event_t event_queue[MAX_EVENTS];
static volatile uint8_t queue_head = 0;
static volatile uint8_t queue_tail = 0;

void queue_event(uint8_t peripheral, uint16_t event, void* data) {
    __disable_irq();
    event_queue[queue_head] = (event_t){peripheral, event, data, get_tick()};
    queue_head = (queue_head + 1) % MAX_EVENTS;
    __enable_irq();
}

Advanced techniques

Context switching optimization. Minimizing overhead means using separate stacks for ISRs where possible, implementing stack overflow detection, and monitoring maximum stack usage during development. For the most critical ISRs, careful register preservation matters:

// Optimize register usage in critical ISRs
__attribute__((naked)) void high_priority_isr(void) {
    asm volatile("push {r0-r3, r12, lr}");
    handle_critical_event();
    asm volatile("pop {r0-r3, r12, pc}");
}

Performance profiling. Tracking real-time metrics, max ISR time, total interrupts, missed deadlines, and CPU usage percentage, gives visibility into whether the system is actually meeting its timing budget under real load.

Real-world results: camera control system

In a multi-sensor camera system managing a high-resolution image sensor at 60fps, a thermal imaging array at 16Hz, continuous distance ranging, a CAN bus network, and a real-time configuration interface, this architecture delivered interrupt response times in the low single-digit microseconds for critical events, real-time deadline compliance above 99%, CPU utilization comfortably under 20% during normal load, and zero missed frames during 48-hour stress testing, while gracefully handling peak loads well into the thousands of interrupts per second.

Compared to the pre-optimization baseline, interrupt latency improved by roughly an order of magnitude, CPU utilization dropped several-fold, memory footprint shrank dramatically compared to a full RTOS approach, and worst-case response time became dramatically more predictable.

Implementation checklist

In the planning phase: map all peripherals to priority levels, calculate worst-case interrupt frequencies, define maximum acceptable response times, and plan memory for queues and buffers. In development: implement lean ISRs with timing validation, build the event queue system with overflow protection, add performance monitoring, and test under maximum load. In validation: measure actual interrupt timing with an oscilloscope, verify priority preemption works correctly, stress test with simultaneous peripheral activity, and confirm graceful degradation under overload.

Key takeaways

Architecture beats optimization, proper interrupt hierarchy design eliminates most performance problems before they occur. Measure everything, you can't optimize what you don't profile, so build measurement in from day one. Plan for worst case, design for peak load scenarios, not typical operation. Keep ISRs simple, the fastest ISR does minimal work and defers processing intelligently. And test relentlessly, real-world interrupt timing often surprises even experienced developers.

Why it matters at Hoomanely

This interrupt-driven architecture has been refined across multiple projects, where our camera and sensor systems need the kind of real-time reliability traditional approaches can't deliver. Robust firmware architecture like this is the foundation for technology that responds to the world with the reflexes and reliability continuous pet health monitoring demands.

Read more