_ISR_Handler

[Joel Sherrill]

Allan Hessenflow wrote:
>>> As part of doing a bf537 bsp, I've written a new blackfin interrupt
>>> handler.
>>> It seems to work.  However, I see at least one problem with the
>>> _ISR_Handler
>>> documentation at:
>>> http://www.rtems.org/onlinedocs/releases/rtemsdocs-4.8.0/share/rtems/html/porting/porting00035.html
>>>
>>> So, I'm hoping someone who understands the RTEMS interrupt handling better
>>> than I could take a look to see if the rest is okay, so I can try to get
>>> it right before submitting any code.
>>>
>>> The problem I'm fairly certain is present in that example is that it
>>> never decrements _Thread_Dispatch_disable_level.
>>>
>>>       
>> I tried to read this assembly to help you out but bfin
>> assembly is a bit cryptic to me.
>>     
>
> I meant that the pseudo-code in the document referenced above doesn't
> decrement _Thread_Dispatch_disable_level, not the existing bfin code.
> The existing bfin code has a couple of other problems unrelated to that
> document; I have written a version that solves those.
>
> Anytime I see a documentation problem, I'm immediately suspicious of
> the rest of the section, hence my question.
>
>   
I would be suspicious in this case.  This code is tricky and
the implementation is unique to a CPU. 

The key is that the value starts at 0.  It should only
go to 1 when a signal is sent to the currently executing
thread from an ISR.  It will be cleared as part of the
ISR_Handler code deciding that is why it needs to
dispatch.

But I have a suspicion that if you had a context switch
necessary and an ISR signal to thread, the ISR signal
to thread would get "stuck high" for a bit too long.
It would take a subsequent interrupt to clear it when
it caused a _Thread_Dispatch that it didn't need to.

I am prone to think it would be safer to ALWAYS clear
it in the generic _Thread_Dispatch and not make the
individual ports do anything but read it. 

It is Monday and this is a subtle issue.  I would appreciate
some feedback.
>> When the documentation is not clear, I always refer to the m68k
>> port on these things.  It is the easiest to read IMO.   It clears
>> the _ISR_Signals_to_thread_executing only if it is needed.  The
>> SPARC is also fairly easy to read and it does the same thing.
>>     
>
> Okay, I'll use m68k as my reference...
>   
Unfortunately, the sequence of events I described above
may cause a a subsequent ISR to call _Thread_Dispatch
even on that port.

I will have to try to construct a test that does this.  Without
a test case, I have trouble trusting my analysis.

--joel
> allan
>
> --
> Allan N. Hessenflow      allanh at kallisti.com
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985