In this lesson, you will learn how to calculate the impact of Interrupt Service Routine (ISR) execution time on your task scheduling latency to ensure your real-time system meets its timing deadlines.
The Cost of Preemption
In an RTOS, a task is running until an interrupt occurs. When an interrupt triggers, the CPU immediately pauses the current task to execute the ISR. This "stolen" time is what we call ISR Latency. If your ISR takes too long to execute, it can delay the start of critical tasks, potentially causing a deadline miss in a hard real-time system.
To maintain determinism, you must treat the time spent inside ISRs as part of the total overhead that prevents your highest-priority tasks from executing immediately.
Calculating the Impact
The latency experienced by a task (T) is effectively:
Latency = (Time spent in ISRs) + (Context Switch Time)
If you have a periodic task with a period of 10ms and a Worst-Case Execution Time (WCET) of 5ms, but your system handles high-frequency serial interrupts that take 1ms to process every 2ms, your task will be effectively delayed.
Consider this logic:
// ISR for high-priority external sensor
void ISR_Sensor_Handler(void) {
// 1. Acknowledge Interrupt (Hardware latency)
// 2. Perform minimal data capture (e.g., read GPIO)
// 3. Post a message to a task queue (Defer the rest)
// 4. Return (CPU resumes interrupted task)
}
If the ISR_Sensor_Handler performs heavy computation, the delay propagates to your scheduler. To minimize this, follow the "Top-Half/Bottom-Half" approach: use the ISR (Top-Half) only to capture data or signal an RTOS primitive (like a semaphore or queue), and let a dedicated task (Bottom-Half) process the data. This allows the RTOS to manage the priority of the heavy processing rather than letting the ISR block the system blindly.
By quantifying the maximum duration of all ISRs that can preempt your critical task, you can subtract that time from your task’s "slack time" to verify that your system architecture remains robust under peak load.
Key Takeaway: To preserve real-time responsiveness, minimize ISR execution time by offloading heavy processing to high-priority RTOS tasks, ensuring the sum of all ISR durations does not cause your critical tasks to exceed their timing constraints.