How to Use Interrupts in Applications

[Joel Sherrill]

Robert S. Grimes wrote:
> 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!
>   
Agreed.  He definitely needs to be spending more time on that
than us right now. :)
> 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...)
>
>   
The documentation needs to reflect the code. 

The current documentation is correct for the simple
vectored interrupt manager used by most ports.  So
it needs to be kept.

The x86, powerpc, and arm use the PIC interrupt model
and it needs to be documented.

I don't know how to present that in the manual so it is
obvious.  My first guess is two interrupt manager
chapters with a huge warning that this chapter is
the API used by architectures X, Y, and Z.
> 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.
>   

No one else is working on this.  Documentation is thankless
work.   But I would definitely give you a big Thank You
for taking a stab at it.

I can provide a rough framework for a chapter in the User's
Guide if you want to fill it in.

--joel
>>   
>>     
> 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
>>>     
>>>       
>>   
>>     
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>