Interrupt

In embedded systems, interrupts are mechanisms used to communicate between a processor and connected devices. The basic idea is that the device gets a task to do, and it will let us know when it’s done. They have powerful applications, including in multitasking, handling unexpected conditions, and operating system calls/protection. The term interrupt is interchangeable with the term exception.

More details on the specific mechanism below. Most interrupt mechanisms are architecture-specific, so more at more specific pages.

• Nios II interrupts
• RISC-V interrupts
• ARM interrupts
• x86 interrupts

Hardware-level

There may be several wires between the device and the CPU for requesting and granting interrupts — a process called a handshake.

When the processor gets an interrupt, the address of the interrupted instruction (the next one to be executed) is stored in a special register (in Nios II, this is in ea/r29; in RISC-V this is in the SEPC).

There’s two main mechanisms some architectures use to store the reason of the exception.

• The first is to include a register that stores the cause (in Nios II, this is in ctl4; in RISC-V, this is the SCAUSE register).
  • This means that the interrupt handler must probe the cause of the interrupt.
• The other is vectored interrupts, which have different exception handler addresses based on the cause of the exception.
  • There may also be an additional base register that holds the address of the “memory space” of the handlers. To get to each handler, we add an offset to it.

Software-level

The architecture may also specify a special return instruction to access the register (eret) when the interrupt handler is done.

Specifically in Nios II, ea will store the instruction after the one that’s been interrupted, i.e., pc+4. At the end of the exception handler, we should subtract the value of ea: subi ea, ea, 4.

Any registers we use must be returned to the state they were at before. We store their values on the stack and pop them when done. The interrupt handler may be hardcoded in at a certain memory address, shared by all interrupt requests. Then software will probe which device requested the interrupt.