How to Use Interrupts in Applications

[Leon Pollak]

On Wednesday 25 July 2007 16:28, Robert S. Grimes wrote:
As everybody is silent, I shall say a few words till others will give more 
wide answer.

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.

Sorry for been so short...

> 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

-- 
Leon