30°C Power On 12 to 36 watts - for fanless sealed system design ...

ESE Magazine Jan/Feb 06
36
Minimizing interrupt
response time: 4 simple rules
David Kleidermacher, Green Hills Software, Inc.
A failure to meet a response time requirement in a real-time system can
be catastrophic. Sound programming coupled with proper RTOS interrupt
architecture can ensure a minimal yet guaranteed worst case response time.
1. Keep interrupt service
routines (ISRs) short
Avoid loops and other constructs which increase
latency. When an interrupt fires, the microprocessor
typically disables interrupts before
executing the ISR. By keeping ISRs simple,
developers avoid the common pitfall of leaving
interrupts disabled for too long, increasing the
latency of higher priority interrupts.
2. Do not disable interrupts
A major contributor to increased latency is the
number and length of regions in which the operating
system disables interrupts. By disabling
interrupts, the kernel increases latency of high
priority events that arrive in those disabling windows.
Most operating systems employ what we
call a Simple architecture, which is easy to
implement: in order to prevent preemption, the
kernel disables interrupts for the duration of the
critical section
By disabling interrupts, the Simple RTOS is
sacrificing the latency of the highest priority
event to avoid problems caused by handling of
lower priority interrupts. A better solution,
implemented in the Advanced architecture, is to
never disable interrupts in kernel service calls.
Not only does the Advanced RTOS guarantee
the minimum possible latency for the highest
priority interrupt, but also the worst case latency
can be trivially proven.
3. Avoid improper use of operating
system API calls in ISRs
ISRs commonly do not require kernel API
access: the ISR performs basic operations
before acknowledging the interrupt and
returning. A more complex ISR is required to
wake up a thread, such as by releasing a
semaphore, for higher level processing. The
RTOS vendor should limit ISRs to a small set
of service calls that are necessary and deterministic.
As an example of the peril regarding API
usage in ISRs, consider a queue of threads
waiting for a resource (e.g. a semaphore).
Many Simple RTOSes use an ordinary linked
list to hold the queue of threads. When the
resource becomes available, the first thread,
regardless of its importance relative to other
waiters, is provided the resource. In contrast,
the Advanced RTOS automatically wakes up
the highest priority waiting thread. Some
Simple RTOSes have a service call that pulls
the highest priority thread out of the queue and
jams it onto the front. One problem with this
approach is its usability: the developer must
remember to insert prioritisation calls and
determine where in the code they belong.
Worse, the RTOS must search linearly through
the unordered list to find the highest priority
thread; real-time behaviour is lost.
The Advanced architecture provides a second-level
handler, sometimes termed a callback,
to perform higher level processing
when the kernel has returned to a consistent
state. If the developer must add a callback in
the ISR and then write code in the callback to
do the service call, this makes programming
more difficult. Not to worry: the Advanced
RTOS hides the details of two-level handling
by allowing the use of a standard API call
which places the callback on behalf of the
programmer.
There are some important advantages to the
Advanced architecture’s optional two-level handler.
By pushing work into the callback (where
interrupts are enabled), the Advanced RTOS
reduces the temporal footprint of the ISR, in turn
reducing the latency for higher priority interrupts
(Figure 1). Note that the overhead of the twolevel
handling is negligible: a callback entails
merely placing a function address on a list for
the kernel to call; no heavyweight processing or
memory is required.
4. Properly prioritise interrupts
relative to threads
When a thread is awakened for higher level processing
of the most important event, this thread
becomes the most important thread in the system.
The thread must complete its processing
within a fixed period of time.
In the Simple RTOS, the thread runs with all
interrupts enabled. Any low priority interrupt can
fire, delaying the most important thread and
Figure 1: Reducing latency for higher
priority interrupts.
Figure 2: Minimum response time for events.
causing missed deadlines. In fact, since interrupts
may nest, multiple events, and all of their
associated ISR processing, could delay this high
priority processing by an unpredictable length of
time.
The Advanced RTOS allows interrupts to be
prioritised relative to threads. When a high priority
thread is awakened during interrupt processing,
the kernel inhibits lower priority interrupts
when switching to the high priority thread.
When the high priority thread completes its
work, the kernel reenables lower priority interrupts.
This architecture guarantees the minimum
thread response time for the highest priority
real-time events (Figure 2).
Complex embedded systems, with multiple
concurrent tasks and interrupt sources, pose a
challenge for RTOS interrupt handling architecture.
Developers will achieve the best interrupt
response time by following a few simple rules
and employing an RTOS with an Advanced interrupt
architecture.
www.ghs.com