Shaun Jackman <sjackman@nospam.vortek.com> wrote:
Great! This fixed my problem. Thanks for you quick reply. I don’t fully
understand what the problem is though. The implicit InterruptMask() of
InterruptWait() is matched with my explicit InterruptUnmask() every single
time.
Here is your code again:
: #define RTC_IRQ 0
: ThreadCtl( _NTO_TCTL_IO, 0);
: SIGEV_INTR_INIT( &event);
: hInterrupt = InterruptAttachEvent( RTC_IRQ, &event, 0);
: for( i = 0; i < 100; i++) {
: printf( “%d\n”, i);
: InterruptWait( 0, NULL);
: InterruptDisable();
: // do stuff
: InterruptUnmask( RTC_IRQ, hInterrupt);
: InterruptEnable();
On your 100th loop, at this point an interrupt is generated, the
interrupt is automatically masked…
: }
You fall out of the loop, rather than doing an InterruptWait() and
InterruptUnmask().
: InterruptDetach( hInterrupt);
And, now, the interrupt is (almost) permanently masked.
I don’t see how an extra InterruptMask() could sneak in to leave the
interrupt inadvertently disabled. What magic is QNX doing when the TRK_MSK
flag is specified?
QNX maintains a mask counter for the interrupt level on a system global
basis, each time a mask is performed (InterruptMask() or each event
attached to that interrupt level), this counter is increment. On each
InterruptUnMask() this counter is decremented. When this counter goes
to 0, the interrupt is actually unmasked at the PIC (hardware) level.
Setting TRK_MSK creates a per-process counter of how many masks & unmasks
are “owned” by that process. If the process counter is greater than 0
when the process exits, that number of “unmasks” will be applied to the
system global counter. In essence, this flag asks the OS to cleanup
after your process properly on process exit.
If this flag is necessary, I suggest putting your exact
words into the documentation for InterruptAttachEvent().
It is not strictly neccessary – if you disable your hardware
before exiting, so you will never have a pending mask for your
process at exit time, or if you are not sharing interrupt levels
(that is, you don’t have more than one handler/event attached to
a particular interrupt level) then you don’t need this. But, most
of the time, and especially during development when things might go
unexpectedly wrong, it is usually good to have. I will pass on a
suggestion to docs (a PR) that this should be more strongly worded.
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
{