Hello,
I could use some help on a piece of code. I am working with an interupt
handler. I need to find a way to have a function (FuncA) wait for the
interrupt handler (FuncB) to start. I wanted to use a Semaphore (post in
FuncB and wait in FuncA) but that just crashes QNX. Does anyone have any
suggestions?
Thanks,
Chris.
Interupt handler help
Re: Interupt handler help
In article <bjo30p$sbf$1@inn.qnx.com>, cph@videk.com says...
You might want to read Programmer's Guide
http://www.qnx.com/developer/docs/momen ... ndler.html
Shortly, you need InterruptAttach() your ISR (FuncB) and when you return pointer to the event
structure from this ISR, FuncA, previously blocked on InterruptWait() will start its work. Bring
your attention, you're very limited in ISR (FuncB), you can use only interrupt safe operations. ISR
is supposed to deal with hardware (source of interrupt requests) mainly.
Best regards,
Eduard
Hello,Hello,
I could use some help on a piece of code. I am working with an interupt
handler. I need to find a way to have a function (FuncA) wait for the
interrupt handler (FuncB) to start. I wanted to use a Semaphore (post in
FuncB and wait in FuncA) but that just crashes QNX. Does anyone have any
suggestions?
Thanks,
Chris.
You might want to read Programmer's Guide
http://www.qnx.com/developer/docs/momen ... ndler.html
Shortly, you need InterruptAttach() your ISR (FuncB) and when you return pointer to the event
structure from this ISR, FuncA, previously blocked on InterruptWait() will start its work. Bring
your attention, you're very limited in ISR (FuncB), you can use only interrupt safe operations. ISR
is supposed to deal with hardware (source of interrupt requests) mainly.
Best regards,
Eduard
Re: Interupt handler help
ed1k <ed1k@humber.bay> wrote:
ek > In article <bjo30p$sbf$1@inn.qnx.com>, cph@videk.com says...
ek > You might want to read Programmer's Guide
ek > http://www.qnx.com/developer/docs/momen ... ndler.html
ek > Shortly, you need InterruptAttach() your ISR (FuncB) and when you return pointer to the event
ek > structure from this ISR, FuncA, previously blocked on InterruptWait() will start its work. Bring
ek > your attention, you're very limited in ISR (FuncB), you can use only interrupt safe operations. ISR
ek > is supposed to deal with hardware (source of interrupt requests) mainly.
I caught one phrase that you said in your original post. Maybe I'm
making more of it than you intended. But you said you wanted FuncA
to wait until FuncB *started*. I don't think this can be done. You
will be notified when FuncB finishes.
ek > In article <bjo30p$sbf$1@inn.qnx.com>, cph@videk.com says...
ek > Hello,Hello,
I could use some help on a piece of code. I am working with an interupt
handler. I need to find a way to have a function (FuncA) wait for the
interrupt handler (FuncB) to start. I wanted to use a Semaphore (post in
FuncB and wait in FuncA) but that just crashes QNX. Does anyone have any
suggestions?
Thanks,
Chris.
ek > You might want to read Programmer's Guide
ek > http://www.qnx.com/developer/docs/momen ... ndler.html
ek > Shortly, you need InterruptAttach() your ISR (FuncB) and when you return pointer to the event
ek > structure from this ISR, FuncA, previously blocked on InterruptWait() will start its work. Bring
ek > your attention, you're very limited in ISR (FuncB), you can use only interrupt safe operations. ISR
ek > is supposed to deal with hardware (source of interrupt requests) mainly.
I caught one phrase that you said in your original post. Maybe I'm
making more of it than you intended. But you said you wanted FuncA
to wait until FuncB *started*. I don't think this can be done. You
will be notified when FuncB finishes.
Re: Interupt handler help
This is something that threw me for a while. You can't do much in a QNX ISR.
If your term "interrupt handler" means ISR, then you can't get there. Spend
some time in the QNX programmer's guide and figure out what the architecture
permits. You will end up with an ISR that triggers an Interrupt Handler. The
Interrupt Handler will do most of the work that I would typically expect to
do in an ISR, without the restrictions on making blocking calls.
You probably want to post the sem, or better, send a pulse in the Interrupt
Handler(FcnB) and wait on that message in FcnA. It's kind of roundabout, but
it's what you have to do.
Regards,
Dave Kuechenmeister
"Chris Haidvogel" <cph@videk.com> wrote in message
news:bjo30p$sbf$1@inn.qnx.com...
If your term "interrupt handler" means ISR, then you can't get there. Spend
some time in the QNX programmer's guide and figure out what the architecture
permits. You will end up with an ISR that triggers an Interrupt Handler. The
Interrupt Handler will do most of the work that I would typically expect to
do in an ISR, without the restrictions on making blocking calls.
You probably want to post the sem, or better, send a pulse in the Interrupt
Handler(FcnB) and wait on that message in FcnA. It's kind of roundabout, but
it's what you have to do.
Regards,
Dave Kuechenmeister
"Chris Haidvogel" <cph@videk.com> wrote in message
news:bjo30p$sbf$1@inn.qnx.com...
Hello,
I could use some help on a piece of code. I am working with an interupt
handler. I need to find a way to have a function (FuncA) wait for the
interrupt handler (FuncB) to start. I wanted to use a Semaphore (post in
FuncB and wait in FuncA) but that just crashes QNX. Does anyone have any
suggestions?
Thanks,
Chris.
Re: Interupt handler help
Thanks for all the good info.
This one is more of an opinion question. The driver I am working on
originally implemented the interrupt using InterruptAttach. This made the
method it called a true life ISR. I would like to rewrite it using an
additional thread and the InterruptAttachEvent funtion. Would I be taking a
performance hit if I reimplement the driver with InterruptAttachEvent?
Also, does anyone know of anywhere I can find a compare/contrast of
implementing a system with either of those commands?
Thanks again.
Chris.
"ed1k" <ed1k@humber.bay> wrote in message
news:MPG.19c96b3f8b302b109896f5@inn.qnx.com...
This one is more of an opinion question. The driver I am working on
originally implemented the interrupt using InterruptAttach. This made the
method it called a true life ISR. I would like to rewrite it using an
additional thread and the InterruptAttachEvent funtion. Would I be taking a
performance hit if I reimplement the driver with InterruptAttachEvent?
Also, does anyone know of anywhere I can find a compare/contrast of
implementing a system with either of those commands?
Thanks again.
Chris.
"ed1k" <ed1k@humber.bay> wrote in message
news:MPG.19c96b3f8b302b109896f5@inn.qnx.com...
In article <bjo30p$sbf$1@inn.qnx.com>, cph@videk.com says...
Hello,
I could use some help on a piece of code. I am working with an interupt
handler. I need to find a way to have a function (FuncA) wait for the
interrupt handler (FuncB) to start. I wanted to use a Semaphore (post
in
FuncB and wait in FuncA) but that just crashes QNX. Does anyone have
any
suggestions?
Thanks,
Chris.
Hello,
You might want to read Programmer's Guide
http://www.qnx.com/developer/docs/momen ... ndler.html
Shortly, you need InterruptAttach() your ISR (FuncB) and when you return
pointer to the event
structure from this ISR, FuncA, previously blocked on InterruptWait() will
start its work. Bring
your attention, you're very limited in ISR (FuncB), you can use only
interrupt safe operations. ISR
is supposed to deal with hardware (source of interrupt requests) mainly.
Best regards,
Eduard
Re: Interupt handler help
Chris Haidvogel wrote:
addition to the interrupt latency that either approach would experience.
InterruptAttachEvent, then I would recommend using it, since your
handler is then schedulable, permitting improved control.
There will be a performance hit in the form of scheduling latency inThanks for all the good info.
This one is more of an opinion question. The driver I am working on
originally implemented the interrupt using InterruptAttach. This made the
method it called a true life ISR. I would like to rewrite it using an
additional thread and the InterruptAttachEvent funtion. Would I be taking a
performance hit if I reimplement the driver with InterruptAttachEvent?
addition to the interrupt latency that either approach would experience.
If the deadline specs for your app allow you to get away with usingAlso, does anyone know of anywhere I can find a compare/contrast of
implementing a system with either of those commands?
InterruptAttachEvent, then I would recommend using it, since your
handler is then schedulable, permitting improved control.