In a standard C++ interview for a desktop role, interrupts rarely come up. In a Systems Architect interview, they are the heartbeat of the discussion. An ISR is a function called directly by hardware, and it operates under a set of constraints so strict that breaking them almost guarantees a system hang or a non-deterministic crash.
1. The Execution Environment of an ISR
When an interrupt occurs, the CPU stops whatever it is doing, saves the current context (registers, program counter), and jumps to the address in the Interrupt Vector Table.
-
High IRQL: You are running at a high priority level. This means the scheduler is often disabled.
-
No Thread Context: The ISR doesn’t “belong” to any thread. You cannot use thread-local storage or assume a specific stack size.
-
Non-Reentrancy: By default, many systems disable other interrupts while one is running. If your ISR takes too long, you will “miss” other hardware events.
2. The “Golden Rules” of ISR Programming
This is what the interviewer is looking for. If you mention these, you pass the “Embedded 101” test.
A. Do NOT Block
You cannot call mutex_lock(), sleep(), or delay(). If the mutex is held by a lower-priority thread, and the ISR waits for it, you create a Deadlock because the lower-priority thread can never run to release the lock (since the ISR has higher priority).
B. Avoid Heavy I/O (printf)
printf() is often buffered and involves complex string formatting. It is notoriously slow and non-reentrant. In an ISR, use a fast, memory-mapped logging mechanism or toggle a GPIO pin for debugging.
C. No Dynamic Allocation (malloc / free)
The heap is shared. If the main thread was in the middle of a malloc() call when the interrupt fired, the heap’s internal data structures might be in an inconsistent state. Calling malloc() again from the ISR will cause memory corruption.
D. Keep it Short (The Top-Half/Bottom-Half Pattern)
An ISR should only do the bare minimum:
-
Acknowledge the hardware interrupt.
-
Read/Write the critical data to a buffer.
-
Schedule a “Tasklet” or “Deferred Procedure Call” (DPC) to do the heavy processing later at a lower priority.
3. The volatile and static Connection
How do you share data between an ISR and your main() loop?
volatile bool data_ready = false; // Must be volatile!
void Timer_ISR() {
data_ready = true;
}
int main() {
while (!data_ready); // Busy wait
// Process data
}
If data_ready is not volatile, the compiler might optimize the while loop into an infinite loop, assuming data_ready can never change because it’s not changed inside main().
4. Architect’s “Senior” Question: Floating Point in ISRs
Q: Can you perform floating-point math in an ISR?
A: Generally, No. On many architectures (like ARM Cortex-A), the Floating Point Unit (FPU) registers are not saved by default during an interrupt to save time. If an ISR uses the FPU, it will overwrite the floating-point calculations of the interrupted thread. If you must use it, you must manually save/restore the FPU state, which adds massive latency.
5. Summary Table: ISR Restrictions
| Operation | Allowed? | Why? |
| Bitwise Ops | Yes | Fast, deterministic. |
printf() |
No | Slow, uses locks, non-reentrant. |
malloc() |
No | Heap corruption risk, non-deterministic. |
| Mutex Lock | No | Causes priority inversion and deadlocks. |
| Semaphores | Only “Give” | You can signal a task, but never “Take” (wait). |
Architect’s Interview Tip
When talking about ISRs, mention Latency and Jitter. An architect’s job is to ensure that the “Interrupt Latency” (the time from the hardware signal to the first line of ISR code) is minimized. Mentioning that you use Tightly Coupled Memory (TCM) for the ISR code to avoid cache misses shows you are thinking at the silicon level.
In the next article, we move to the C++ side of the world: Object-Oriented Embedded C++ and the cost of Virtual Functions.
Ready for Article 6?
