Interrupt vector table in Embedded C - Time & Space Complexity
When working with an interrupt vector table, it's important to understand how the time to find and run an interrupt handler changes as the number of interrupts grows.
We want to know how the system's response time scales when more interrupts are added.
Analyze the time complexity of the following code snippet.
// Interrupt vector table example
void (*interrupt_vector_table[10])(void);
void handle_interrupt(int interrupt_number) {
if (interrupt_number >= 0 && interrupt_number < 10) {
interrupt_vector_table[interrupt_number]();
}
}
This code stores pointers to interrupt handlers in an array and calls the correct handler based on the interrupt number.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Accessing the interrupt handler from the array by index.
- How many times: Exactly once per interrupt handled.
The time to call the interrupt handler stays the same no matter how many interrupts are in the table.
| Input Size (number of interrupts) | Approx. Operations |
|---|---|
| 10 | 1 |
| 100 | 1 |
| 1000 | 1 |
Pattern observation: The time to find and call the handler does not increase as the number of interrupts grows.
Time Complexity: O(1)
This means the time to handle an interrupt is constant and does not depend on how many interrupts exist.
[X] Wrong: "More interrupts mean longer time to find the right handler because the table is searched one by one."
[OK] Correct: The interrupt vector table uses direct indexing, so the handler is found immediately without searching.
Understanding how direct indexing keeps interrupt handling fast shows your grasp of efficient hardware-software interaction, a valuable skill in embedded programming.
"What if the interrupt vector table was replaced by a linked list of handlers? How would the time complexity change?"