Fwd: Re: Timing of events in an ISR
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Tue Oct 19 17:10:26 UTC 2004
Mark VanderVoord wrote:
>>Could the problem be your interrupt source is
>>asserts its irq, which
>>is inadvertently being masked somewhere such that no
>>then the next time the timer tick comes along the
>>vectoring code sees
>>the asserted irq and then handles it- essentially 1
>>timer tick late?
> It certainly seems that way. I ran the experiment at
> a few additionaly rates (changing
> MICROSECONDS_PER_TICK) and came up with similar
> results. The delay is better, on the average, as the
> tick time gets smaller. Also, it is always smaller
> than one tick time (which matches with your
> suggestion, that the ISR is being run on the following
> normal timer tick).
> If the interrupt is being masked, where would that
> occur? If the hardware interrupt was being masked,
> the event would never happen, correct? So I must be
> masking it in RTEMS? Shouldn't it be disallowed from
> running in this case also?
I don't have your BSP but you might want to look at the clock tick
ISR and see how it resets the timer and ACKS the interrupt.
It may be tickling more than it is supposed to and enabling
That doesn't explain when it gets disabled though. :(
> Mark S VanderVoord
> Self-Guided Systems, LLC
> Do you Yahoo!?
> Declare Yourself - Register online to vote today!
Joel Sherrill, Ph.D. Director of Research & Development
joel at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the users