HighIntegritySystems

Interrupt Service Routines (ISRs)

Interrupts and ISRs ISRs and Tasks

When programming an ISR, it is important to remember

On a microprocessor system, an interrupt is a signal from
that the lowest-priority ISR will always pre-empt the
hardware or software that needs immediate attention. The 2. The ISR runs and
highest-priority Task. While an ISR
blocks is running, other Tasks
the task.
Task that is running must save its state on its stack and
and functions are delayed, potentially causing irregular
control passes to an Interrupt Service Routine (ISR) to handle
processing of lower-priority Tasks. Therefore, it is advisable
the interrupt, shown in Figure 1. Once the ISR is completed
to keep the ISR as short as possible.
the state that was saved on the stack is used to resume
normal operations. ISR
Ideally, the ISR should merely collect data and reset the
2. The ISR runs and interrupt source. Whenever possible, further processing
blocks the task. Task be deferred to Tasks, as illustrated in Figure 2. The
should
elapsed time of an ISR should be short compared with the
intervals between interrupts. This Time can avoid undesirable
delays in processing of
1. The Interrupt other functions. 3. The ISR handles the
occurs while a interrupt, clears the interrupt
ISR task is running. and unblocks the task.
An example of this is when data must be converted to
Task
another format, rather than stored in its original format. The
conversion can be deferred to a Task and interrupts re-
enabled immediately.
Time
1. The Interrupt 3. The ISR handles the
1. The Interrupt 2. The ISR
occurs while a interrupt, clears the interrupt
occurs while runs and
task is running. and unblocks the task.
Task 1 is running. blocks Task 1.

Figure 1. The Interrupt Service Routine (ISR)

ISR
How interrupts are handled is dependent on both the
1. The Interrupt 2. The ISR
hardware
occursand
while the Real-Time
runs and Operating System (RTOS). A

microprocessor will provide

Task 1 is running. blocks Task 1.
a number of hardware interrupts Task 2
to be used by system devices and peripherals, as well
as a number of programmable software interrupts that Task 1
the engineer can use. An RTOS typically requires a timer
interrupt
ISR to maintain an internal time base.
Time
The microprocessor includes different priorities for different
Task 2
types of interrupts. In some cases the microprocessor may 3. The ISR handles the interrupt, 4. Task 2 completes processing
and activates Task 2, which has requested by the interrupt, and enters
support the nesting of interrupts and allow the RTOS to higher priority than Task 1. the Blocked state until triggered by the
Task 1
manage this. Interrupts are now enabled again. ISR again. Task 1 resumes.

An ISR (also called an interrupt handler) takes its priority Figure 2. The Deferred Processing Model
from that of the interrupt. Priorities Time assigned to interrupts are
entirely separate from priorities assigned to Tasks; ISRs will
pre-empt any running Task.
3. The ISR handles the interrupt,
and activates Task 2, which has
4. Task 2 completes processing
requested by the interrupt, and enters
higher priority than Task 1. the Blocked state until triggered by the
Interrupts are now enabled again. ISR again. Task 1 resumes.

SAFERTOS provides API functions that are designed

to be safe to use inside an ISR.

WITTENSTEIN high integrity systems email: [email protected]

Americas: +1 408 625 4712 web: www.highintegritysystems.com
ROTW: +44 1275 395 600
Critical Code Sections • Interrupted Tasks must be resumed after the interrupt
processing has completed, as if nothing has changed.
Critical code sections are sections of code that must be • Errors in ISRs can be difficult to debug and correct,
executed as an atomic whole; they cannot be interrupted.
especially as the effect may show up later in time than
RTOS macros are inserted into the code to indicate the
beginning and end of the critical code sections. the execution of the error.
• The ISR must be able to complete, else the hardware
In a simple, un-nested system the RTOS will turn off interrupts may not be left in the correct state to receive another
for the duration of the critical code sections, delaying the
interrupt.
operation of the interrupt until after the critical code section
has completed. This introduces Interrupt latency. The length
Typically an RTOS will have an alternative set of API calls that
of critical sections should be minimised, as interrupts usually
can be safely used from within an ISR. These ISR friendly
need to be processed as quickly as possible.
API calls will not block or wait for events, semaphores or
data on queues. Calling a standard API call that blocks/
In a nested system it is possible to set an interrupt priority
waits for events from within an ISR will result in indeterminate
threshold level. If a specific interrupt is assigned a priority level
behaviour and it is likely the application will lock up or crash.
above the interrupt priority threshold level, the interrupt will
not be disabled during critical code sections. This reduces
the effect of interrupt latency, however an interrupt set above
RTOS and ISRs
this level must not use any RTOS API calls. If the interrupt is
Subject to hardware capabilities and programming choices
assigned a priority level below the interrupt priority threshold
by the engineer, on the ISR the RTOS can:
level then it will be disabled during critical code sections, but
interrupt friendly RTOS API calls can be used, and it could
result in interrupt latency. • Save the system context (flags, registers etc.);
• Disable all interrupts, unless specifically set by the
Setting an interrupt with a priority level above the interrupt engineer to allow other interrupts;
priority threshold level is a technique used to achieve highly
• Identify the interrupt that has occurred and take default
accurate, precision interrupt timing, and is frequently used in
motor control applications. actions, subject to the specific programming of the
application;
Interrupt Processing • At the end of processing, restore the system context
from the stack or variables;
Microcontrollers use an interrupt controller to manage
the way that asynchronous events are recognised and • Re-enable all the blocked interrupts and resume
presented to the processing unit. These broadly take the execution of the interrupted Task.
form of a vectored interrupt model or a centralised interrupt
handler model.

The centralised interrupt handler model works by the

hardware monitoring or polling multiple interrupt sources
and invoking a single interrupt handler within the software.
The software is then responsible for determining the source
of the interrupt and processing the event.

A vectored interrupt uses a table known as the “Vector

Table” to go directly to the start of the ISR that handles the
interrupt with that vector. The engineer is responsible for
programming the ISR and ensuring it is correctly entered into
the vector table. However, at run time much of the interrupt
handling (such as saving registers) is directly controlled by
the hardware.

Considerations with ISRs

Programming ISRs needs special care.

WITTENSTEIN high integrity systems
• Interrupts by their nature are asynchronous and can
occur in any order. Worldwide Sales and Support
Americas: +1 408 625 4712
• Errors can arise from processing that inadvertently
ROTW: +44 1275 395 600
depends on a state that may not exist at runtime. Email: [email protected]

WITTENSTEIN high integrity systems email: [email protected]

Americas: +1 408 625 4712 web: www.highintegritysystems.com
ROTW: +44 1275 395 600