Day 51: Interrupts, exceptions, and bus arbitration
Interrupts, exceptions, and bus arbitration
Interrupts let a peripheral asynchronously signal the CPU (a UART byte arrived, a timer expired); the CPU finishes the current instruction, saves state, and jumps to a handler, then resumes. Exceptions are the synchronous cousins — raised *by* an instruction (illegal opcode, misaligned access, environment call). Both use the same trap machinery: save the PC, switch to handler code, restore on return.
The alternative to interrupts is polling (spin-checking a status bit) — simple but wastes cycles. Interrupts are efficient but need care (save/restore, priorities, avoiding races). When several masters share a bus (CPU, DMA), bus arbitration decides who drives it each cycle. ChipX's peripherals (Stage 2) raise interrupt lines; its timer and GPIO are your first real interrupt sources.
Interrupt vs polling vs DMA — the BARC/ISRO favorite
'When would you use interrupts vs polling vs DMA?' is a staple government-interview question. The crisp framing: polling for simple/tight-latency loops, interrupts for infrequent asynchronous events, DMA for bulk data movement — and combinations (DMA completion raising an interrupt). You'll implement the interrupt path for real in ChipX's peripherals.
Key terms
- Interrupt
- An asynchronous hardware request that diverts the CPU to a handler, then resumes.
- Exception / trap
- A synchronous event raised by an instruction, handled by the same save/restore machinery.
- Handler / ISR
- The routine that services an interrupt or exception.
- Polling
- Repeatedly reading a status bit instead of waiting for an interrupt.
- Bus arbitration
- Deciding which master drives a shared bus each cycle.
Before moving on, you should be able to
How does an exception differ from an interrupt?
