Is the Interrupt Controller (i8259A) programmed by QNX4 to be sensitive to
the rising front of the request or to the high level of it?
I’m developing a board where I must “or” together several IRQs before
delivering to the ISA contact. I need to make sure that there will be no
IRQ stuck…
The async.c will scan all the IRQ sources on the board to find the active
one. I’m afraid of the situation when an IRQ will rise on one of the
sources RIGHT AFTER it (that particular source) was just interrogated.
I can make a hardware facility to “and” the "or"ed line with a zero-level
signal for a brief moment to produce the rising front on the already high
IRQ line if I’ve missed an active source just before the async.c is about
to return.
This, I believe, will not be nesessary if i8259A is “level-activated”.
Please comment.
Tony.
PS
This assumes that the serviced source will lower it’s IRQ pin. It will
indeed.
PPS
Who sends the EOI (EndOfInterrupt) command to i8259A - should it be my
async.c or it’s done whithin QNX4 itself automagically?
Is the Interrupt Controller (i8259A) programmed by QNX4 to be sensitive to
the rising front of the request or to the high level of it?
For ISA bus cards, it is rising edge-triggered. For PCI bus cards,
it is level-triggered.
PPS
Who sends the EOI (EndOfInterrupt) command to i8259A - should it be my
async.c or it’s done whithin QNX4 itself automagically?
QNX4 itself will automagically issue the EOI after the last interrupt
handler for the interrupt has finished executing, but before any process
is scheduled.
On 13 Apr 2005 16:16:46 GMT, David Gibbs <dagibbs@qnx.com> wrote:
QNX4 itself will automagically issue the EOI after the last interrupt
handler for the interrupt has finished executing, but before any process
is scheduled.
Uh, oh!..
This makes my life harder still.
How should one handle the situation when the IRQ is issued again during
the (I hope a very short one) time gap between the async.c’s “return” and
the moment QNX4 issues the EOI?
Since I must not send the EOI myself, the best I could think of is
something like the following:
unsigned char pending;
unsigned int ORedIRQline; /* the port number to read the state of the
request line */
while ( pending=inp(ORedIRQline) ){
/* search and service the IRQ sources on the board */
}
return;
I believe, if I might insert the EOI command and the momentarily zeroing
of the IRQ line in between the closing bracket of “while” and the “return”
that would make it 100% reliable…
Otherwise, I may only hope that nothing happens on the board after I left
“while” loop and before QNX4 issues the EOI…
On 13 Apr 2005 16:16:46 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:
QNX4 itself will automagically issue the EOI after the last interrupt
handler for the interrupt has finished executing, but before any process
is scheduled.
Uh, oh!..
This makes my life harder still.
If all the interrupt are comming into a single ISR that’s not problem. The
ISR must loop through all the devices to check if one has generated an
interrupt, process that interrupt and loop again untill all devices have not
interrupt request pending.
This I’ve done multiple time with Quatek serial card that are able to share
IRQ. Works well.
If you want multiple ISR you are screwed. I don’t think filling with the
8259 is a good idea unless you can tell exactly what QNX is doing with it.
I don’t think fidlling with the 8259 is a good idea unless you can tell
exactly what QNX is doing with it.
No, I do not even think of re-programming the PIC.
I’ve read (at last) the PDF on 8259. The only shadow of doubt remains
because Intel comments on level-trigged mode that one must have IRQ line
in the low state when the EOI is issued, otherways the ISR will be called
again. (Which I see as a “safety-net” for a missed request)
And there is no such a comment on edge-trigged mode…
Tony.
PS
Intuitevelly I agree that Intel’s engineers are smart enough to provide us
with the reliable device. It’s all on us to use it properly.
Once I had a bad story [mis]using the Intel’s CAN chip. If two messages
arrived very close to one another - my system got stuck with the unserved
CAN’s IRQ because my ISR did not check that there were no more requests
pending on the chip before returning…
On Thu, 14 Apr 2005 12:04:07 -0400, Mario Charest <postmaster@127.0.0.1
wrote:
If all the interrupt are comming into a single ISR that’s not problem.
Yes, I plan to serve all the sources on the board with the single ISR.
If you want multiple ISR you are screwed.
Do you mean that someone may want to serve a part of the sources on the
board with one piece of code, return from it and wait till QNX launces
another to serve the remaining devices there? Weird idea, IMHO.
Not quite
Let says your board as a serial port and digitals io, both sharing the same
IRQ… I would make sense to have a driver for each devices.
Each driver would register their own handler. When an interrupt is trigger,
QNX calls all the handlers registered on that interrupt. Each handler is
responsible for looking if the hardware they are managing, generated their
interrupt. This will work fine for PCI. Because if an IRQ is generated by
the first devices while the second handler is running, when all ISR have
been called, QNX will detect the pending interrupt and start the cylcle
again., On ISA it won’t work, because that extra interrupt will be missed.
To deal with that you must loop one extra time until there are no more
pending interrupts. You can’t do that if the the ISR are in separete
process.
