Interrupt Service Routine (ISR)

An ISR must execute as quickly as possible to minimize the time the processor spends in the interrupt context, which blocks other tasks. This is quantified by its Worst-Case Execution Time (WCET).

• Design Principle: ISRs should perform only the most essential work, such as reading a sensor value from a hardware register or setting a flag.
• Prohibited Actions: Complex computations, blocking operations (e.g., waiting for I/O), or calls to non-reentrant functions are avoided.
• Real-World Impact: In a 1kHz motor control loop, an ISR triggered by a timer must complete in significantly less than 1ms to leave ample time for the main control algorithm.

The time from interrupt signal arrival to the start of ISR execution must be predictable and bounded. This interrupt latency and its variation (jitter) are critical for hard real-time systems.

• Factors Affecting Latency: Maximum interrupt disable time, higher-priority ISRs, and context switch overhead.
• Jitter Control: A key goal is to minimize jitter to ensure periodic control loops (e.g., for a robotic joint) have stable timing. Tickless RTOS kernels can reduce jitter from system timer interrupts.
• Measurement: This is often validated using an oscilloscope to probe a GPIO pin toggled at the ISR's entry and exit.

ISRs must not block and should be designed for reentrancy—the ability to be safely interrupted and called again before a previous invocation has finished.

• Shared Data Hazard: If an ISR and a main task share a variable (e.g., a sensor data buffer), corruption can occur if the main task is interrupted mid-write.
• Synchronization Mechanisms: Simple shared flags or lock-free ring buffers are preferred. Traditional mutexes or semaphores that can cause blocking are typically forbidden inside ISRs.
• Best Practice: The ISR writes data to a buffer and sets an atomic flag; the main task's thread polls this flag and processes the data.

Interrupts are assigned hardware or software priorities. A higher-priority interrupt can preempt a lower-priority ISR that is currently executing, ensuring the most critical events are serviced first.

• Nested Interrupts: Many microcontrollers allow higher-priority interrupts to preempt lower-priority ones, which must be explicitly enabled and managed to avoid stack overflow.
• Priority Inversion Mitigation: In systems where an ISR and a task share a resource, techniques like priority inheritance (often managed by the RTOS) prevent a medium-priority task from blocking a high-priority ISR.
• Example: In an autonomous vehicle, a LiDAR data-ready interrupt (high priority) would preempt a routine temperature sensor ISR (low priority).

Upon entry, the ISR must save the processor's context (register states) of the interrupted task. Upon exit, it must restore this context precisely so the interrupted task can resume as if nothing happened.

• Hardware Assistance: The processor's interrupt controller often automatically saves the program counter and status registers to the stack.
• Software Responsibility: The ISR prologue (often compiler-generated) saves other CPU registers. The epilogue restores them and executes a special return-from-interrupt instruction.
• System Integrity: Incorrect context saving/restoring is a common source of catastrophic, difficult-to-debug failures in embedded systems.

To maintain brevity, an ISR often defers non-urgent processing to a scheduled task or a deferred procedure. This separates time-critical response from time-consuming computation.

• Common Patterns:
  • Task Notification: The ISR sends a direct notification or signal to a waiting RTOS task.
  • Work Queue: The ISR posts a work item to a queue serviced by a lower-priority daemon task.
  • Software Interrupt: A secondary, lower-priority interrupt is triggered for follow-up work.
• Real-Time Benefit: This keeps interrupt latency low and allows complex operations (e.g., parsing a packet, running a PID calculation) to occur in a task context where blocking is permissible.

ISRs provide the lowest-latency path for capturing time-sensitive sensor readings. When a sensor's data-ready pin triggers an interrupt, the ISR immediately reads the value from a peripheral register (e.g., SPI, I2C, ADC) into a memory buffer.

• Key Benefit: Guarantees no data loss from high-frequency sensors like inertial measurement units (IMUs) or rotary encoders.
• Example: A 1kHz IMU generating accelerometer and gyroscope data. The ISR fires every 1ms, reading the sample to ensure the state estimation filter has fresh data for the control loop.
• Architecture: The ISR performs minimal work—just a data copy. Processing (filtering, fusion) is deferred to a lower-priority task.

A hardware timer is configured to generate a periodic interrupt at the exact frequency of the robot's primary control loop (e.g., 100Hz, 1kHz). The corresponding ISR acts as the precise heartbeat for the entire system.

• Function: The timer ISR triggers the execution of the main control task, ensuring deterministic periodicity.
• Critical for: Proportional-Integral-Derivative (PID) controllers and Model Predictive Control (MPC) algorithms, where consistent loop timing is essential for stability and performance.
• Implementation: The ISR often sets a flag or releases a semaphore to wake a high-priority task that runs the control algorithm, keeping the ISR itself short.

This is a safety-critical ISR with the highest priority in the system. It is triggered by hardware fault pins, limit switches, or watchdog timers.

• Immediate Action: The ISR commands all actuators (motors, solenoids) to a safe state (zero torque, engage brakes) within microseconds, overriding any ongoing software commands.
• Non-Maskable Interrupts (NMIs): Often used for this purpose, as they cannot be disabled by software.
• Fault Logging: The ISR may capture a snapshot of system state (register values, sensor readings) to non-volatile memory for post-failure analysis before executing the safe shutdown.

ISRs manage the low-level protocol handling for real-time communication peripherals, ensuring timely transmission and reception of critical data.

• UART/Serial: An ISR fires when a byte is received, placing it into a ring buffer to prevent overrun, crucial for parsing commands from a main computer.
• CAN Bus: A message reception ISR immediately copies the CAN frame ID and data payload, allowing the application to process vehicle network commands with minimal delay.
• Ethernet with Time-Sensitive Networking (TSN): While more complex, dedicated hardware and ISRs can service precise time slots for scheduled traffic, enabling synchronized motion across a distributed robot fleet.

For precise motor control, ISRs handle the fundamental electrical timing. In Field-Oriented Control (FOC) for brushless DC motors, a PWM timer interrupt triggers the ISR that calculates and updates the next voltage vector.

• High Frequency: These ISRs run at the PWM switching frequency (tens of kHz).
• Encoder Interface: A hardware quadrature encoder counter can generate an interrupt on index pulse or on overflow, allowing for immediate and accurate position capture for closed-loop servo control.
• Consequence: Missing these interrupts causes torque ripple, inefficiency, or loss of synchronization.

Poorly designed ISRs can cripple a real-time system. Adherence to strict rules is mandatory.

• Keep it Short: ISRs must execute in a few microseconds. Defer any non-critical processing (e.g., complex math, logging) to a task.
• Avoid Blocking Operations: Never call functions that may wait (e.g., malloc, mutex locks without timeout, printing to a slow console).
• Re-entrancy & Shared Data: Protect shared data accessed by an ISR and a task using atomic operations or lock-free ring buffers. Disable interrupts briefly if necessary.
• Priority Management: Assign ISR priorities based on urgency. A limit switch fault must preempt a periodic sensor read.
• Measure Worst-Case Execution Time (WCET): The sum of all possible ISR executions within a period must be factored into real-time schedulability analysis.

A hard real-time constraint is a system requirement where missing a specified deadline results in a total system failure, potentially causing catastrophic consequences. This is distinct from soft real-time, where missed deadlines degrade performance but do not cause failure.

ISRs are critical in hard real-time systems, such as robotic actuator control or aviation flight controllers. Their execution must be:

• Extremely short (often measured in microseconds) to avoid blocking higher-priority interrupts.
• Predictable, with a known and verified Worst-Case Execution Time (WCET).
• Deterministic, meaning their timing is repeatable for identical conditions.

Worst-Case Execution Time (WCET) is the maximum possible time a specific piece of code, such as an ISR, can take to execute on given hardware under all possible inputs and system states. Determining WCET is not about average performance but about absolute upper bounds.

For ISR design, WCET analysis is non-negotiable:

• It is a fundamental input for schedulability analysis, proving all tasks and interrupts can meet their deadlines.
• It dictates how much work can safely be done inside the ISR versus deferred to a lower-priority task.
• Analysis methods include static analysis of the machine code and measurement-based testing under extreme conditions.

Priority inversion is a problematic scenario in real-time scheduling where a high-priority task (H) is indirectly preempted by a lower-priority task (L) for an unbounded time, violating priority-based scheduling rules. A classic sequence:

1. L acquires a mutex protecting a shared resource.
2. H preempts L but then blocks, waiting for the same mutex.
3. A medium-priority task (M) preempts L, preventing L from finishing and releasing the mutex, thus indirectly blocking H.

This is critically relevant to ISRs if they use synchronization primitives. Mitigations include:

• Priority inheritance protocols, where L temporarily inherits H's priority while holding the mutex.
• Designing ISRs to be non-blocking, avoiding mutexes altogether.

Direct Memory Access (DMA) is a hardware feature that allows peripherals (e.g., ADCs, serial ports, camera sensors) to transfer data directly to and from system memory without continuous CPU intervention. The CPU initiates the transfer, then the DMA controller handles the data movement, generating an interrupt only upon completion.

DMA is essential for efficient ISR design in robotics:

• It dramatically reduces CPU load and interrupt frequency for high-bandwidth I/O (e.g., LiDAR point clouds, inertial measurement unit streams).
• It allows an ISR to process a large block of data (e.g., a full image frame) with a single interrupt at the end of transfer, rather than one interrupt per byte or word.
• This enables shorter, more predictable ISR execution times.

Deferred interrupt handling (often called a bottom half in Linux kernel terminology) is a design pattern that splits interrupt processing into two parts:

1. Top Half (ISR): The immediate, time-critical routine. It performs minimal work—acknowledging the hardware, saving crucial data—and schedules deferred processing.
2. Bottom Half: A less-critical routine that handles the bulk of data processing. It runs later, outside of interrupt context, often as a kernel tasklet, workqueue, or a dedicated RTOS task.

This pattern is crucial for maintaining low interrupt latency. For example, a network interface ISR might simply move a packet to a queue, while a separate task processes the packet's contents, preventing the ISR from blocking other interrupts.