Zero interrupt latency

Interrupt latency is the time that passes between the occurrence of an interrupt request and the subsequent execution of the first instruction of the respective interrupt service routine. This is a critical component of overall RTOS latency. Every computer system involves interrupt latency, the duration of which depends on various factors and may differ even on the same computer system. The most interesting value is the worst-case interrupt latency. The interrupt latency is a sum of a lot of different smaller delays explained below.
This is important when critical code should be executed as soon as possible once an interrupt occurs. For example, an emergency switch is intended to stop a machine at once, and the code in the respective interrupt routine will stop the machine. It is essential, and may be even life-threatening, if the interrupt service routine is delayed in doing so. This variation in delay is often called RTOS jitter.

• The first delay is typically caused by hardware: The interrupt request signal needs to be synchronized to the CPU clock. Depending on the synchronization logic, up to 3 CPU cycles may expire before the interrupt request has reached the CPU core.

• The CPU will typically complete the current instruction, which may take several cycles. On most systems, divide, push-multiple or memory-copy instructions are the most time-consuming instructions to execute. On top of the cycles required by the CPU, additional cycles are often required for memory accesses. In an ARM7 system, the instruction STMDB SP!,{R0-R11,LR} typically is the worst-case instruction, storing 13 register of 32-bit each to the stack, and takes 15 clock cycles to complete.

• 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 on the stack (typically PC and flag registers). Modern CPUs such as ARM generally perform a mode switch, which takes 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.

• An embedded RTOS also needs to temporarily disable the interrupts that could call API functions of the RTOS. Some RTOSes disable all interrupts, effectively worsening interrupt latency for all cases. Some other, including embOS, disable low-priority interrupts only and thus will not affect the latency of high-priority interrupts — a key feature for a deterministic RTOS.

Most CPUs support interrupts with different priorities. The exact amount of different levels of interrupt priorities depends on the CPU and the interrupt controller in use. Different priorities have two effects:

• If different interrupts occur simultaneously, the interrupt with higher priority takes precedence and its ISR is executed first.

• Interrupt execution can be intermitted by other interrupts of higher priority
• The CPU interrupt level can be configured to a specific value, which disables all interrupts with an interrupt priority below this value.

Instead of disabling all interrupts when embOS does atomic operations, the interrupt level of the CPU is set to a specific threshold. Therefore, all interrupts with interrupt priorities higher than this threshold can still be processed. These interrupts are named zero latency interrupts. All interrupts with priority level below the threshold are disabled. These interrupts are named embOS interrupts.

embOS will never add any RTOS latency to the zero latency interrupts. Therefore, they will be executed as fast as it were without RTOS at all. This makes it easy to use time-critical interrupt service routines with embOS, ensuring your industrial RTOS or safety-critical application responds deterministically.