Robert Krten <email@example.com> wrote in article <firstname.lastname@example.org>…
Rejean Senecal <> email@example.com> > wrote:
From the “Building Embedded Systems” Appendix A in the QNX web site.
It is stated that the IRQ7 and IRQ15 are unreliable. Can someone explain
why. Here is a copy of the text.
"On an x86 design, the QNX default startup supports two Programmable
Interrupt Controllers (PICs). These must be 8259-compatible, with the
standard configuration of a secondary 8259 connected to the IRQ2 line of the
primary interrupt controller.
Beware of hanging devices off IRQ7 and IRQ15 on an 8259 chip – these
are generally known as the “glitch interrupts” and can be unreliable."
It’s because they’re generally known as the glitch interrupts and can be
Seriously, though, I believe that it stems from the design of the 8259 chip,
wherein any interrupt that cannot (for whatever reason) be identified as
originating on a particular IRQ channel are assigned to the last channel.
IRQ 7 is the last channel on the 1st controller, and IRQ 15 is the last
channel on the 2nd controller.
I think that on today’s “modern hardware” you might be safe, but a hardware
expert will need to comment. Or, look at the i8259 datasheet…
Well, here is piece of Intel Peripheral Components book, p. 3-177:
“If no interrupt request is present at step 4 of either sequence (i.e. the request was too short
in duration) the 8259A will issue an interrupt level 7. Both the vectoring bytes and the CAS lines
will look like an interrupt level 7 was requested.”
There is the same information for 82C59A-2 on page 3-200.
An interrupt request is executed by raising an IR input (low to high), and holding it high until it
is acknowledged (Pay attention - the CPU has to set INTA pulse twice and only during second pulse
the 8259A releases an 8 bit pointer for interrupt) in Edge Triggered Mode, or just by high level on
an IR input in Level Trigered Mode.
So, if any device in your system put short interrupt request pulse - the interrupt 7
occurs for first interrupt controller, and the interrupt 15 occurs for second one.
Good hardware design is the way to avoid this situation. From other hand, you can run into it under
heavy radio interference, you have to know it and you’ll safe. I don’t think IRQ7 and IRQ15 are
“unreliable”, just they share “glitch interrupt requests” as well. Modern hardware “All-in-chip”
just doesn’t issue wrong requests inside itself, IMO
I’m surprised by QNX document which covers such specific aspect. (I did not read that appendix yet
) Good work, guys. Nice to have such documentations. Thanks.
ed1k at ukr dot net
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.