Timing of events in an ISR

[Joel Sherrill <joel@OARcorp.com>]

Mark VanderVoord wrote:
> I've discovered something which I think supports
> Joel's theory about the problem.
> 
> In the spi task (TA1 in the sample files in the last
> attachment), if I replace 
> 
> rtems_event_receive(1,RTEMS_WAIT|RTEMS_EVENT_ALL,0,&temp);
> 
> with 
> 
> while
> (rtems_event_receive(1,RTEMS_NO_WAIT|RTEMS_EVENT_ALL,0,&temp));
> 
> the response time drops to less than 10 usec (which is
> what I was originally expecting).  At first I thought
> this disagreed with my previous results, as I have
> already shown that the delay was occuring before the
> ISR was called.
> 
> Then I realized that this seems to support Joel's idea
> that my IDLE thread may have an error which is making
> it non-preemptable until the tick timer goes off.  If
> this were the case (but my normal task is ok), then it
> would cause this behavior, right?
> 
> Is there any way I can determine what the IDLE
> thread's mode settings are?

If you are in gdb, then you can print out *_Thread_Idle
and look at the boolean is_preemptible.

But it is more likely that if you broken inside the IDLE
thread that you would see an SR that doesn't allow
your SPI interrupt.  It could be a variation on the
MIPS bug mentioned earlier in this thread.

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