Getting Started with QNX Neutrino - QNX Software Systems

Writing interrupt handlers
© 2009, QNX Software Systems GmbH & Co. KG.
on us. With InterruptAttachEvent(), the kernel has no idea whether or not the
hardware event that caused the interrupt was “significant” for us, so it drops the event
on us every time it occurs, masks the interrupt, and lets us decide if the interrupt was
significant or not.
We handled the decision in the code example for InterruptAttach() (above) by
returning either a struct sigevent to indicate that something should happen, or by
returning the constant NULL. Notice the changes that we did to our code when we
modified it for InterruptAttachEvent():
• The “ISR” work is now done at thread time in main().
• We must always unmask the interrupt source after receiving our event (because the
kernel masks it for us).
• If the interrupt is not significant to us, we don’t do anything and simply loop
around again in the for statement, waiting for another interrupt.
• If the interrupt is significant to us, we handle it directly (in the case IIR_MSR
part).
Where you decide to clear the source of the interrupt depends on your hardware and
the notification scheme you’ve chosen. With the combination of SIGEV_INTR and
InterruptWait(), the kernel doesn’t “queue” more than one notification; with
SIGEV_PULSE and MsgReceive(), the kernel will queue all the notifications. If you’re
using signals (and SIGEV_SIGNAL, for example), you define whether the signals are
queued or not. With some hardware schemes, you may need to clear the source of the
interrupt before you can read more data out of the device; with other pieces of
hardware, you don’t have to and can read data while the interrupt is asserted.
An ISR returning SIGEV_THREAD is one scenario that fills me with absolute fear! I’d
recommend avoiding this “feature” if at all possible.
In the serial port example above, we’ve decided to use InterruptWait(), which will
queue one entry. The serial port hardware may assert another interrupt immediately
after we’ve read the interrupt identification register, but that’s fine, because at most one
SIGEV_INTR will get queued. We’ll pick up this notification on our next iteration of
the for loop.
InterruptAttach() versus InterruptAttachEvent()
This naturally brings us to the question, “Why would I use one over the other?”
The most obvious advantage of InterruptAttachEvent() is that it’s simpler to use than
InterruptAttach() — there’s no ISR routine (hence no need to debug it). Another
advantage is that since there’s nothing running in kernel space (as an ISR routine
would be) there’s no danger of crashing the entire system. If you do encounter a
programming error, then the process will crash, rather than the whole system.
However, it may be more or less efficient than InterruptAttach() depending on what
you’re trying to achieve. This issue is complex enough that reducing it to a few words
182 Chapter 4 • Interrupts April 30, 2009