Preferred method to signaling an Interrupt Cause

bridged with qdn.public.ddk
Post Reply
Andre Goddard Rosa

Preferred method to signaling an Interrupt Cause

Post by Andre Goddard Rosa » Tue Oct 14, 2003 7:34 pm

Hi!

I would like to know what is the preferred method to indicate an
interruption cause
when using and ISR and also a thread to handling interrupts.
I am using the SIGEV_INTR flag to unblock an InterruptWait() function but I
need
to indicate to the thread being unblock what was the cause. Just an int
could be the
case.

Questions:

How can I make this int variable be shared between the ISR and the thread?
(I need
to write to this variable in the ISR and read this value on the thread)

Do I need some lock mecanism before reading this variable on the thread?
(like disabling
interrupts, reading the value and enabling the interrupts)


Thanks, I appreciate any help,

Andre

Mario Charest

Re: Preferred method to signaling an Interrupt Cause

Post by Mario Charest » Tue Oct 14, 2003 11:05 pm

"Andre Goddard Rosa" <goddard@audiolab.com.br> wrote in message
news:bmhi6k$gq$1@inn.qnx.com...
Hi!

I would like to know what is the preferred method to indicate an
interruption cause
when using and ISR and also a thread to handling interrupts.
I am using the SIGEV_INTR flag to unblock an InterruptWait() function but
I
need
to indicate to the thread being unblock what was the cause. Just an int
could be the
case.

Questions:

How can I make this int variable be shared between the ISR and the thread?
(I need
to write to this variable in the ISR and read this value on the thread)
If it's an int you don't need any locking mecanism because operation on int
are atomic (unlike int64).
Make sure the variable is declared as volatile.

Do I need some lock mecanism before reading this variable on the thread?
(like disabling
interrupts, reading the value and enabling the interrupts)


Thanks, I appreciate any help,

Andre

Andre Goddard Rosa

Re: Preferred method to signaling an Interrupt Cause

Post by Andre Goddard Rosa » Wed Oct 15, 2003 5:03 pm

Thanks, Mario! Much appreciated. :)

Andre

"Mario Charest" <postmaster@127.0.0.1> escreveu na mensagem
news:bmhv95$8ld$1@inn.qnx.com...
"Andre Goddard Rosa" <goddard@audiolab.com.br> wrote in message
news:bmhi6k$gq$1@inn.qnx.com...
Hi!

I would like to know what is the preferred method to indicate an
interruption cause
when using and ISR and also a thread to handling interrupts.
I am using the SIGEV_INTR flag to unblock an InterruptWait() function
but
I
need
to indicate to the thread being unblock what was the cause. Just an int
could be the
case.

Questions:

How can I make this int variable be shared between the ISR and the
thread?
(I need
to write to this variable in the ISR and read this value on the thread)

If it's an int you don't need any locking mecanism because operation on
int
are atomic (unlike int64).
Make sure the variable is declared as volatile.



Do I need some lock mecanism before reading this variable on the thread?
(like disabling
interrupts, reading the value and enabling the interrupts)


Thanks, I appreciate any help,

Andre



David Gibbs

Re: Preferred method to signaling an Interrupt Cause

Post by David Gibbs » Tue Oct 21, 2003 6:33 pm

Andre Goddard Rosa <goddard@audiolab.com.br> wrote:
Hi!

I would like to know what is the preferred method to indicate an
interruption cause
when using and ISR and also a thread to handling interrupts.
I am using the SIGEV_INTR flag to unblock an InterruptWait() function but I
need
to indicate to the thread being unblock what was the cause. Just an int
could be the
case.

Questions:

How can I make this int variable be shared between the ISR and the thread?
(I need
to write to this variable in the ISR and read this value on the thread)
All global variables (and, in fact, the entire data space of your process)
is available to the interrupt handler.

volatile unsigned hw_status;

const struct sigevent *
int_handler(...)
{
....
hw_status = ...;
return &event;
}

....
while(1)
{
InterruptWait(...);
if (hw_status)...
}
Do I need some lock mecanism before reading this variable on the thread?
(like disabling
interrupts, reading the value and enabling the interrupts)
For checking, no.

If the operation you later do depends...it may get more complex.

-David
--
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Post Reply

Return to “qdn.public.ddk”