I’m presently attempting to convert the Neutrino sample capture utility for
BT848/BT878 capture cards to QNX 4.24. The card is currently functioning
properly if I just randomly take samples from the DMA buffers, however, when
I enable interrupt events on the card, QNX 4.24 freezes.
I’m using the following to trap the interrupt.
#pragma off( check_stack );
pid_t far handler()
{
counter=1;
return( 0 );
}
#pragma on( check_stack );
…
dev->irq_id=qnx_hint_attach( dev->irq, &handler, FP_SEG( &counter ) );
If I use qnx_hint_mask( dev->irq, 2 ); before activating the interrupt on
the card, there are no lockups, however, when I use qnx_hint_mask( dev->irq,
1 ); the system immediately freezes.
If I set dev->irq to the mouse interrupt, there are no freezes, and the
interrupt handler works normally when I move the mouse.
Any help is appreciated!
Jack Harmon
Jack Harmon <me@work.com> wrote:
JH > I’m presently attempting to convert the Neutrino sample capture utility for
JH > BT848/BT878 capture cards to QNX 4.24. The card is currently functioning
JH > properly if I just randomly take samples from the DMA buffers, however, when
JH > I enable interrupt events on the card, QNX 4.24 freezes.
JH > I’m using the following to trap the interrupt.
JH > #pragma off( check_stack );
JH > pid_t far handler()
JH > {
JH > counter=1;
JH > return( 0 );
JH > }
JH > #pragma on( check_stack );
JH > …
JH > dev->irq_id=qnx_hint_attach( dev->irq, &handler, FP_SEG( &counter ) );
JH > If I use qnx_hint_mask( dev->irq, 2 ); before activating the interrupt on
JH > the card, there are no lockups, however, when I use qnx_hint_mask( dev->irq,
JH > 1 ); the system immediately freezes.
JH > If I set dev->irq to the mouse interrupt, there are no freezes, and the
JH > interrupt handler works normally when I move the mouse.
JH > Any help is appreciated!
JH > Jack Harmon
Is it possible that the interrupts are occuring too frequently?
I.E. There is not NON-interrupted time left over.
Jack Harmon wrote:
I’m presently attempting to convert the Neutrino sample capture utility for
BT848/BT878 capture cards to QNX 4.24. The card is currently functioning
properly if I just randomly take samples from the DMA buffers, however, when
I enable interrupt events on the card, QNX 4.24 freezes.
I suppose you have to put some code into the interrupt handler to
clean the int request state on your device, else the kernel will get
re-interrupted just after each EOI command gived to the PIC… that is
the “freeze” condition you are describing.
Attaching your routine to the mouse IRQ does not freeze QNX because on
each mouse interrupt the kernel calls it (nothing important is done
there) AND then it calls the mouse driver interrupt routine, that will
clear the int request from the mouse itself.
Davide
Should I simply unmask the interrupt in the callback instead of the handler,
or do I need to kill it on the card. The Neutrino example code simply
unmasks the interrupt in the handler, but since QNX 6 handles interrupts
differently, the logic doesn’t seem to work the same for both.
Thanks for the info!
Jack Harmon
“Davide Ancri” <nospam@please.me> wrote in message
news:ccua3i$r0k$1@inn.qnx.com…
Jack Harmon wrote:
I’m presently attempting to convert the Neutrino sample capture utility
for
BT848/BT878 capture cards to QNX 4.24. The card is currently
functioning
properly if I just randomly take samples from the DMA buffers, however,
when
I enable interrupt events on the card, QNX 4.24 freezes.
I suppose you have to put some code into the interrupt handler to
clean the int request state on your device, else the kernel will get
re-interrupted just after each EOI command gived to the PIC… that is
the “freeze” condition you are describing.
Attaching your routine to the mouse IRQ does not freeze QNX because on
each mouse interrupt the kernel calls it (nothing important is done
there) AND then it calls the mouse driver interrupt routine, that will
clear the int request from the mouse itself.
Davide
That is possible, but unmasking the interrupt in the callback doesn’t seem
to be fast enough either. Things are happening quicker than in the example
on Neutrino since that code simply unmasks the interrupt inside the
interrupt handler.
Thanks!
Jack Harmon
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:ccua54$qvo$1@inn.qnx.com…
Jack Harmon <> me@work.com> > wrote:
JH > I’m presently attempting to convert the Neutrino sample capture
utility for
JH > BT848/BT878 capture cards to QNX 4.24. The card is currently
functioning
JH > properly if I just randomly take samples from the DMA buffers,
however, when
JH > I enable interrupt events on the card, QNX 4.24 freezes.
JH > I’m using the following to trap the interrupt.
JH > #pragma off( check_stack );
JH > pid_t far handler()
JH > {
JH > counter=1;
JH > return( 0 );
JH > }
JH > #pragma on( check_stack );
JH > …
JH > dev->irq_id=qnx_hint_attach( dev->irq, &handler, FP_SEG(
&counter ) );
JH > If I use qnx_hint_mask( dev->irq, 2 ); before activating the
interrupt on
JH > the card, there are no lockups, however, when I use qnx_hint_mask(
dev->irq,
JH > 1 ); the system immediately freezes.
JH > If I set dev->irq to the mouse interrupt, there are no freezes, and
the
JH > interrupt handler works normally when I move the mouse.
JH > Any help is appreciated!
JH > Jack Harmon
Is it possible that the interrupts are occuring too frequently?
I.E. There is not NON-interrupted time left over.
Jack Harmon <me@work.com> wrote:
JH > Should I simply unmask the interrupt in the callback instead of the handler,
JH > or do I need to kill it on the card. The Neutrino example code simply
JH > unmasks the interrupt in the handler, but since QNX 6 handles interrupts
JH > differently, the logic doesn’t seem to work the same for both.
JH > Thanks for the info!
JH > Jack Harmon
You need to clear the interrupt in the handler or else
as soon as the ISR exits the OS will re-call it.
Ah! Your looking in the wrong place!
Here’s the deal. Your IO device generates an interrupt on one of the IRQ#
lines. The 8259A generates an interrupt to the CPU. The CPU calls an
appropriate ISR for the interrupt that was generated.
Before the ISR returns it needs to tell the IO device to stop generating
the IRQ. It usually does this by reading a status register. Or it may
send a command to the device to tell it to stop generating the IRQ. In any
case, if the ISR returns and the IRQ line is still active, the CPU will
immediately re-call the ISR.
So, . . . . you need to know what to do for the device that you are
programming to clear the interrupt on it.
Jack Harmon <me@work.com> wrote:
JH > Thanks for the info, however, I’ve searched all the documentation I have and
JH > cannot find any references to CLEARING the interrupt other than a warning
JH > NOT to reprogram the 8259 to clear it. I’ve found the qnx_hint functions,
JH > as well as _enable and _disable, but still nothing on clearing it.
JH > Any further help is appreciated!
JH > Thanks!
JH > Jack Harmon
JH > “Bill Caroselli” <qtps@earthlink.net> wrote in message
JH > news:ccurk5$ad0$1@inn.qnx.com…
Jack Harmon <> me@work.com> > wrote:
JH > Should I simply unmask the interrupt in the callback instead of the
JH > handler,
JH > or do I need to kill it on the card. The Neutrino example code
JH > simply
JH > unmasks the interrupt in the handler, but since QNX 6 handles
JH > interrupts
JH > differently, the logic doesn’t seem to work the same for both.
JH > Thanks for the info!
JH > Jack Harmon
You need to clear the interrupt in the handler or else
as soon as the ISR exits the OS will re-call it.
–
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net
Thanks for the info, however, I’ve searched all the documentation I have and
cannot find any references to CLEARING the interrupt other than a warning
NOT to reprogram the 8259 to clear it. I’ve found the qnx_hint functions,
as well as _enable and _disable, but still nothing on clearing it.
Any further help is appreciated!
Thanks!
Jack Harmon
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:ccurk5$ad0$1@inn.qnx.com…
Jack Harmon <> me@work.com> > wrote:
JH > Should I simply unmask the interrupt in the callback instead of the
handler,
JH > or do I need to kill it on the card. The Neutrino example code
simply
JH > unmasks the interrupt in the handler, but since QNX 6 handles
interrupts
JH > differently, the logic doesn’t seem to work the same for both.
JH > Thanks for the info!
JH > Jack Harmon
You need to clear the interrupt in the handler or else
as soon as the ISR exits the OS will re-call it.
WOOHOO! That dunnit! =)
Thanks a ton!
Jack Harmon
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:ccuvq6$d3e$2@inn.qnx.com…
Ah! Your looking in the wrong place!
Here’s the deal. Your IO device generates an interrupt on one of the IRQ#
lines. The 8259A generates an interrupt to the CPU. The CPU calls an
appropriate ISR for the interrupt that was generated.
Before the ISR returns it needs to tell the IO device to stop generating
the IRQ. It usually does this by reading a status register. Or it may
send a command to the device to tell it to stop generating the IRQ. In
any
case, if the ISR returns and the IRQ line is still active, the CPU will
immediately re-call the ISR.
So, . . . . you need to know what to do for the device that you are
programming to clear the interrupt on it.
Jack Harmon <> me@work.com> > wrote:
JH > Thanks for the info, however, I’ve searched all the documentation I
have and
JH > cannot find any references to CLEARING the interrupt other than a
warning
JH > NOT to reprogram the 8259 to clear it. I’ve found the qnx_hint
functions,
JH > as well as _enable and _disable, but still nothing on clearing it.
JH > Any further help is appreciated!
JH > Thanks!
JH > Jack Harmon
JH > “Bill Caroselli” <> qtps@earthlink.net> > wrote in message
JH > news:ccurk5$ad0$> 1@inn.qnx.com> …
Jack Harmon <> me@work.com> > wrote:
JH > Should I simply unmask the interrupt in the callback instead of
the
JH > handler,
JH > or do I need to kill it on the card. The Neutrino example code
JH > simply
JH > unmasks the interrupt in the handler, but since QNX 6 handles
JH > interrupts
JH > differently, the logic doesn’t seem to work the same for both.
JH > Thanks for the info!
JH > Jack Harmon
You need to clear the interrupt in the handler or else
as soon as the ISR exits the OS will re-call it.
\
Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net