Fwd: Re: Timing of events in an ISR

[Joel Sherrill <joel@OARcorp.com>]

Mark VanderVoord wrote:
>>Could the problem be your interrupt source is
>>asserts its irq, which
>>is inadvertently being masked somewhere such that no
>>interrupt occurs,
>>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
the interrupt.

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!
> http://vote.yahoo.com


-- 
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