“Eduard” <ed1k@humber.bay> wrote in message
news:MPG.18addadebd962e75989685@inn.qnx.com…
Hi Randy,
void *
timerThread ( void( arg )
something wrong with brackets here…
Yeah, it used to be pvoid_t instead of void*.
I tried replacing the stuff so I wouldn’t have to
explain it all. Obviously that was a mistake.
{
int IRQtimer_id;
int timer;
ThreadCtl( _NTO_TCTL_IO, 0 );
SIGEV_INTR_INIT( &IRQevent );
is IRQevent a global structure?
Yes, pertinent declarations:
typedef void* pvoid_t;
#define ever ;;
//! pitInt_c - Interrupt # for the timer interrupt.
#define pitInt_c 0 //!< PIT interrupt for 8254 timer #0
IRQtimer_id =
InterruptAttachEvent
(
0,
&IRQevent,
0
);
printf( “IRQ id=%d\n”, IRQtimer_id );
if ( IRQtimer_id == -1 )
{
printf
(
“timerThread: Unable to attach to interrupt (irq %u): %s\n”,
pitInt_c,
strerror( errno )
);
exit( EXIT_FAILURE );
}
// wait here forever, handling messages
timer = 0;
for(ever)
{
printf( “Calling Interrupt Wait\n” );
InterruptWait( 0, NULL );
printf( “Calling InterruptUnmask\n” );
InterruptUnmask( pitInt_c, IRQtimer_id );
You use 0 in InterruptAttachEvent(), but pitInt_c here… it’s bad thing,
IMO
The bad thing is that I missed this instance when hand replacing them
by zero for the post.
++timer;
if( timer >= 1 )
{
printf( “Timer interrupt 10,000\n” );
timer = 0;
}
}
}
Are you sure you had written event handler which is fast enough? for 1
miliseconds rate events >
Those printf() eat much more time… I do not think INT 0 is a good
interrupt for such programming,
because this interrupt is used by kernel for sheduling and internal
timers. I believe this is your
problem. I can’t catch why do you try to do this in such way? What’s the
main purpose of this
handler? Why you don’t use timers? If you need hardware generated events
not so fast, you could use
RTC interrupt…
I don’t need a timer interrupt at all.
What I need is a working template of an ISR that I can test on a PC before
moving it to the embedded system. Since the INT 0 interrupt is common on
both (and, in fact, I’ve gotten INT 0 to work fine on the embedded platform
in this manner), I figured it would be a good test of the basic ISR
structure
before moving on. As for race conditions and timing in the thread, as you
can
infer from the code, originally I had it waiting about 10 seconds between
messages
and then dropped it down to one second, and then once per loop when there
was no output. It, literally, never gets pass the InterruptWait.
So something else is going wrong here.
Randy Hyde