Interrupts are interruptions of a program caused by hardware. When an interrupt occurs, the CPU normally saves some of its registers and executes a subroutine called an interrupt service routine, or ISR. After the ISR is completed, the program returns to the highest-priority task in the READY state. Normal interrupts are maskable; they can occur at any time unless they are disabled with the CPU's "disable interrupt" instruction. ISRs are also nestable Œ they can be recognized and executed within other ISRs.
There are several good reasons for using interrupt routines. They can respond very quickly to external events such as the status change on an input, the expiration of a hardware timer, reception or completion of transmission of a character via serial interface, or other events. Interrupts effectively allow events to be processed as they occur.
Interrupt latency is the time between interrupt request and execution of the first instruction of the interrupt service routine. Every computer system has an interrupt latency. The latency depends on various factors and differs even on the same computer system. The value that one is typically interested in is the worst case interrupt latency. The interrupt latency is a sum of a lot of different smaller delays explained below.
The first delay is typically in the hardware: The interrupt request signal needs to be synchronized to the CPU clock. Depending on the synchronization logic, typically up to 3 CPU cycles can be lost before the interrupt request has reached the CPU core.
The CPU will typically complete the current instruction. This instruction can take a lot of cycles; on most systems, divide, push-multiple or memory-copy instructions are the instructions which require most clock cycles. On top of the cycles required by the CPU, there are in most cases additional cycles required for memory access. In an ARM7 system, the instruction STMDB SP!,{R0-R11,LR}; Push parameters and perm. Registers is typically the worst case instruction. It stores 13 32-bit registers on the stack. The CPU requires 15 clock cycles.
The memory system may require additional cycles for wait states.
After completion of the current instruction, the CPU performs a mode switch or pushes registers (typically PC and flag registers) on the stack. In general, modern CPUs (such as ARM) perform a mode switch, which requires less CPU cycles than saving registers.
Pipeline fill
Most modern CPUs are pipelined. Execution of an instruction happens in various stages of the pipeline. An instruction is executed when it has reached its final stage of the pipeline. Since the mode switch has flushed the pipeline, a few extra cycles are required to refill the pipeline.
There can be additional causes for interrupt latencies. These depend on the type of system used, but we list a few of them.
Latencies caused by cache line fill
If the memory system has one or multiple caches, these may not contain the required data. In this case, not only the required data is loaded from memory, but in a lot of cases a complete line fill needs to be performed, reading multiple words from memory.
Latencies caused by cache write back.
A cache miss may cause a line to be replaced. If this line is marked as dirty, it needs to be written back to main memory, causing an additional delay.
Latencies caused by MMU translation table walks.
Translation table walks can take a considerable amount of time, especially as they involve potentially slow main memory accesses. In real-time interrupt handlers, translation table walks caused by the TLB not containing translations for the handler and/or the data it accesses can increase interrupt latency significantly.
Application program.
Of course the application program can cause add. latencies by disabling interrupts. This can make sense in some situations, but of course causes add. latencies.
Interrupt routines
On most systems, one interrupt disables further interrupts. Even if the interrupts are re-enabled in the ISR, this takes a few instructions, causing add. latency.
RTOS (Real Time Operating system)
An RTOS also needs to temporarily disable the interrupts which can call API-functions of the RTOS. Some RTOSes disable all interrupts, effectively worsening interrupt latencies for all interrupts, some (like embOS) disable only low-priority interrupts and do thereby not affect the latency of high priority interrupts.
Zero interrupt latency in the strict sense is not possible as explained above. What we mean when we say "Zero interrupt latency" is that the latency of high priority interrupts is not affected by the RTOS; a system using embOS will have the same worst-case interrupt latency for high priority interrupts as a system running without
Most CPUs support interrupts with different priorities. Different priorities have two effects:
If different interrupts occur simultaneously, the interrupt with higher priority takes precedence and it's ISR is executed first.
Interrupts can never be interrupted by other interrupts of the same or lower level of priority
How many different levels of interrupts there are depends on the CPU and the interrupt controller. Details are explained in the CPU/MCU/SOC manuals and the embOS port specific documentation. embOS distinguishes two different levels of interrupts: High / Low priority interrupts.
The embOS port specific documentation explains where "the line is drawn", which interrupts are considered high and which interrupts are considered low priority.
In general, the differences are:
Low priority interrupts
May call embOS API functions
Latencies caused by embOS
High priority interrupts
May not call embOS API functions
No Latencies caused by embOS (Zero latency)
M16C CPUs support 8 interrupt priority levels. With embOS, the 3 highest priority levels are treated as is "High priority interrupts". ARM CPUs support normal interrupts (IRQ) and fast interrupt (FIQ). Using embOS, the FIQ is treated as is "High priority interrupt".
.