How to Use Interrupts in Applications

Robert S. Grimes rsg at alum.mit.edu
Wed Jul 25 15:47:03 UTC 2007


Leon Pollak wrote:

Hi Leon, small world, eh?
> The new excpetion processing works fine, the routine you found 
> (CPU_ISR_install...) I remember to be a dumb routine. I have no time now to 
> dig into the code (preparing a lot of PDR documentation :-)), but if you will 
> look into any PPC BSP (I used FADS on 860 and 8260 for my BSP as a proto) - 
> everything is there.
>   
Yes, that is what I did, specifically looking into the xiltemac driver
for the PowerPC/Virtex BSP.  When I followed that model, it does indeed
work just fine.  Thanks, Leon, for confirming - Problem solved, for me.
> Sorry for been so short...
>   
Don't apologize - I've been there!  Good luck on your PDR!

Moving on...Now, my problem for my "day job" has been resolved by doing
the same as the BSP does, which really was the main concern of my first
email.  However, in the interest of making things better, I'm still
concerned that there seems to be a major disconnect between the
documentation and the actual code.  New users will understandably expect
the RTEMS C User's Guide to reflect the code, but at least in this case,
it just plain doesn't.  I'd be happy to help somehow, but I don't know
if the intent is to make the new exceptions compatible to the
documentation, or the other way around.  (I actually suspect the latter,
but there likely needs to be some backward compatible mechanisms...)

So what I'm asking is this:  How can I help?  If others are already
working on this, of course I'm fine with that.
>   
wkr,
-Bob
>   
>> Robert S. Grimes wrote:
>>     
>>> Okay, I'm confused.  I'm not at all sure how the concepts of "old
>>> exception model", "new exception model", and the RTEMS "Interrupt
>>> Manager" are related.
>>>
>>> One guess I have is that the first two are strictly BSP constructs, and
>>> that the Interrupt Manager sits on top of whichever choice a BSP has
>>> implemented.  Is that correct?
>>>       
>> Well, I guess not, but maybe that is the intent?  See below...
>>
>>     
>>> I'm using the PowerPC/Virtex BSP off the head, which uses the "new
>>> exception model".  I want to create a relatively simple ISR to handle a
>>> peripheral that is custom to one of several processor boards that all
>>> use the same BSP.  So it seems wise to keep it out of the BSP, and
>>> implement it in my application.  So do I just use the "Interrupt
>>> Manager", and let all the details pertaining to the interrupt controller
>>> be handled by the BSP?
>>>       
>> Nope!
>>
>>     
>>> Is it as simple as this?
>>>
>>>     extern rtems_isr_entry myIsrFunc;
>>>     #define MY_INT_VECTOR  1
>>>
>>>     // Somewhere in my app init code
>>>     rtems_isr_entry oldIsrFunc;
>>>     rtems_interrupt_catch(myIsrFunc, MY_INT_VECTOR, &oldIsrFunc);
>>>       
>> Okay, no, it is not this simple.  the rtems_interrupt_catch eventually
>> gets to c/src/lib/libcpu/powerpc/new-exceptions/cpu.c, where it
>> encounters this code:
>>
>>     void _CPU_ISR_install_vector(<snip>)
>>     {
>>       BSP_panic("_CPU_ISR_install_vector called\n");
>>     }
>>
>> So it is clear to me that the "new exception" model hasn't been fully
>> worked out (yet), at least not at the application level.  It is safe to
>> say that interrupt management is broken here, or the documentation is
>> fully out of date.
>>
>> So what am I to do now?  I'd be happy to help, but I have more unknowns
>> right now about what the thinking was behind the switch from old to
>> new.  I found a discussion in the mailing list archives from a few years
>> ago, but it wasn't complete enough to understand.  I need this _now_,
>> and will cobble something together if forced to (I'm sure the Ethernet
>> driver example will help me), but it doesn't seem right to just solve my
>> problem in an undocumented, quite possibly wrong-headed,, way, and not
>> fix it more generally to help future users!  I just need a bit of
>> direction...
>>
>> Thanks,
>> -Bob
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>     
>
>   



More information about the users mailing list