26.02.2014 Views

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

Getting Started with QNX Neutrino - QNX Software Systems

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

<strong>Neutrino</strong> and interrupts<br />

© 2009, <strong>QNX</strong> <strong>Software</strong> <strong>Systems</strong> GmbH & Co. KG.<br />

END<br />

clear source of interrupt<br />

IF thread required to do some work THEN<br />

RETURN (event);<br />

ELSE<br />

RETURN (NULL);<br />

ENDIF<br />

The trick is to return an event (of type struct sigevent, which we talked about in<br />

the Clocks, Timers, and <strong>Getting</strong> a Kick Every So Often chapter) instead of NULL.<br />

Note that the event that you return must be persistent after the stack frame of the ISR<br />

has been destroyed. This means that the event must be declared outside of the ISR, or<br />

be passed in from a persistent data area using the area parameter to the ISR, or<br />

declared as a static <strong>with</strong>in the ISR itself. Your choice. If you return an event, the<br />

kernel delivers it to a thread when your ISR returns. Because the event “alerts” a<br />

thread (via a pulse, as we talked about in the Message Passing chapter, or via a signal),<br />

this can cause the kernel to reschedule the thread that gets the CPU next. If you return<br />

NULL from the ISR, then the kernel knows that nothing special needs to be done at<br />

thread time, so it won’t reschedule any threads — the thread that was running at the<br />

time that the ISR preempted it resumes running.<br />

Level-sensitivity versus edge-sensitivity<br />

There’s one more piece of the puzzle we’ve been missing. Most PICs can be<br />

programmed to operate in level-sensitive or edge-sensitive mode.<br />

In level-sensitive mode, the interrupt line is deemed to be asserted by the PIC while<br />

it’s in the “on” state. (This corresponds to label “1” in the diagram below.)<br />

Time<br />

Hardware interrupt<br />

request line<br />

1 2 3 2 3 2 3<br />

ISR x<br />

Level-sensitive interrupt assertion.<br />

We can see that this would cause the problem described above <strong>with</strong> the floppy<br />

controller example. Whenever the ISR finishes, the kernel tells the PIC, “Okay, I’ve<br />

handled this interrupt. Tell me the next time that it gets activated” (step 2 in the<br />

diagram). In technical terms, the kernel sends an End Of Interrupt (EOI) to the PIC.<br />

The PIC looks at the interrupt line and if it’s still active would immediately<br />

re-interrupt the kernel (step 3).<br />

We could get around this by programming the PIC into edge-sensitive mode. In this<br />

mode, the interrupt is noticed by the PIC only on an active-going edge.<br />

172 Chapter 4 • Interrupts April 30, 2009

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!