FreeRTOS interrupt priority restrictions - Time & Space Complexity
When working with FreeRTOS, interrupt priority rules affect how often and how quickly interrupts run.
We want to understand how the number of interrupt priority checks grows as more interrupts are used.
Analyze the time complexity of the following code snippet.
// Example ISR with priority check
void vExampleISR(void) {
BaseType_t xHigherPriorityTaskWoken = pdFALSE;
if (uxInterruptPriority <= configMAX_SYSCALL_INTERRUPT_PRIORITY) {
// Safe to call FreeRTOS API
xSemaphoreGiveFromISR(xSemaphore, &xHigherPriorityTaskWoken);
}
portYIELD_FROM_ISR(xHigherPriorityTaskWoken);
}
This code checks if the interrupt priority is allowed to call FreeRTOS APIs and then signals a semaphore.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: The priority check and semaphore give happen every time the interrupt fires.
- How many times: Once per interrupt occurrence, which depends on hardware events.
As the number of interrupts increases, the system must handle more priority checks and context switches.
| Input Size (number of interrupts) | Approx. Operations |
|---|---|
| 10 | 10 priority checks and possible semaphore signals |
| 100 | 100 priority checks and possible semaphore signals |
| 1000 | 1000 priority checks and possible semaphore signals |
Pattern observation: The operations grow linearly with the number of interrupts handled.
Time Complexity: O(n)
This means the time spent checking priorities and handling interrupts grows directly with how many interrupts occur.
[X] Wrong: "Interrupt priority checks happen only once regardless of interrupt count."
[OK] Correct: Each interrupt triggers its own priority check, so more interrupts mean more checks.
Understanding how interrupt priority checks scale helps you design responsive and safe real-time systems.
"What if we decreased configMAX_SYSCALL_INTERRUPT_PRIORITY to allow more interrupts to call FreeRTOS APIs? How would the time complexity change?"