Getting Started with QNX Neutrino - QNX Software Systems

Neutrino and interrupts
© 2009, QNX Software Systems GmbH & Co. KG.
Interrupt service routine
Clearing the interrupt source
In our analogy, telling the kernel that the interrupt was handled would be like telling
the customer the answer — we can return back to whatever we were doing, knowing
that the customer has had their question answered.
Telling the kernel that some action needs to be performed is like telling the customer
that you’ll get back to them — the telephone has been hung up, but it could ring again.
The ISR is a piece of code that’s responsible for clearing the source of the interrupt.
This is a key point, especially in conjunction with this fact: the interrupt runs at a
priority higher than any software priority. This means that the amount of time spent in
the ISR can have a serious impact on thread scheduling. You should spend as little
time as possible in the ISR. Let’s examine this in a little more depth.
The hardware device that generated the interrupt will keep the interrupt line asserted
until it’s sure the software handled the interrupt. Since the hardware can’t read minds,
the software must tell it when it has responded to the cause of the interrupt. Generally,
this is done by reading a status register from a specific hardware port or a block of data
from a specific memory location.
In any event, there’s usually some form of positive acknowledgment between the
hardware and the software to “de-assert” the interrupt line. (Sometimes there isn’t an
acknowledgment; for example, a piece of hardware may generate an interrupt and
assume that the software will handle it.)
Because the interrupt runs at a higher priority than any software thread, we should
spend as little time as possible in the ISR itself to minimize the impact on scheduling.
If we clear the source of the interrupt simply by reading a register, and perhaps stuffing
that value into a global variable, then our job is simple.
This is the kind of processing done by the ISR for the serial port. The serial port
hardware generates an interrupt when a character has arrived. The ISR handler reads a
status register containing the character, and stuffs that character into a circular buffer.
Done. Total processing time: a few microseconds. And, it must be fast. Consider what
would happen if you were receiving characters at 115 Kbaud (a character about every
100 μs); if you spent anywhere near 100 μs handling the interrupt, you wouldn’t have
time to do anything else!
Don’t let me mislead you though — the serial port’s interrupt service routine could
take longer to complete. This is because there’s a tail-end poll that looks to see if more
characters are waiting in the device.
Clearly, minimizing the amount of time spent in the interrupt can be perceived as
“Good customer service” in our analogy — by keeping the amount of time that we’re
on the phone to a minimum, we avoid giving other customers a busy signal.
170 Chapter 4 • Interrupts April 30, 2009