User`s guide

10 Interrupts Versus Polling
10-4
• Interrupt handler entry and exit latency — Because an interrupt can stop
the currently executing task at any instruction and the interrupted task has
to resume proper execution when the interrupting task completes execution,
its state has to be saved and restored accordingly. This includes saving CPU
data and address registers, including the stack pointer. In the case that the
interrupted task executed floating-point unit (FPU) operations, the FPU
stack has to be saved as well (108 bytes on a Pentium CPU). This introduces
additionally latency.
•
Interrupt handler content latency — If a background task has been
executing for a longer time, say in a loop, its needed data will be available in
the cache. But as soon as an interrupt occurs and the interrupt service
handler is executed, the data needed in the interrupt handler might no
longer be in the cache, causing the CPU to reload it from slower RAM. This
introduces additional latency. Generally, an interrupt reduces the optimal
execution speed or introduces latency, because of its unpredictable nature.
The xPC Target real-time kernel in interrupt mode is close to optimal for
executing code on a PC-compatible system. However, interrupt mode
introduces an overall latency of about 8 µs. This is a significant amount of time
when considering that a 1 GHz CPU can execute thousands of instructions
within 8 µs. This time is equivalent to a Simulink model containing a hundred
nontrivial blocks. Additionally, because lower priority tasks have to be serviced
as well, a certain amount of headroom (at least 5%) is necessary, which can
cause additional cache misses and therefore nonoptimal execution speed.
Polling Mode
Polling mode for the xPC Target real-time kernel does not have the 8 µs of
latency that interrupt mode does. This is because the kernel does not allow
interrupts at all, so the CPU can use this extra time for executing model code.
Polling mode is sometimes seen as a “primitive” or “brute force” real-time
execution scheme. Nevertheless, when a real-time application executes at a
given base sample time in interrupt mode and overloads the CPU, switching to
polling mode is often the only alternative to get the application to execute at
the required sample time.