How to Use Interrupts in Applications

[Joel Sherrill]

Robert S. Grimes wrote:
> 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...
>   
Old versus new should really be referred to as "simple vectored"
or "vectored via interrupt controller".  Depending on the CPU
architecture, some CPUs never have an external PIC while others
always have an external PIC.

For example, the m68k and sparc have plenty of vectors and
the CPU directly vectors the interrupt source.  These are the
old or simple vectored model.

On the PowerPC and (by convention) the x86, there is normally an
external PIC. The PIC is technically NOT part of the CPU architecture
and can vary from board to board.  The new interrupt vectoring
is for these architectures.

The problem is that the Interrupt Manager was never really
intended for high level application use.  It is for BSP and device
driver developers.  The new or vectored interrupt model needs
documentation. 

You only get a choice of one or the other depending on the
architecture you are using.  The PowerPC is in the middle because
the original port was to the 4xx series which has plenty of
interrupt vectors so used direct vectors (e.g. old).  The mpc6xx
models which followed do not have enough vectors and thus
are always found with PICs.  The PowerPC is finally nearly completely
converted to the new exception model but given the number of
BSPs it has taken a long time.

Unfortunately a very confusing historical artifact.  We didn't
name the models correctly and ended up with old and new when
each is appropriate for different architectures.

If someone could write up User's Manual suitable documentation
for the PIC Interrupt Model, I would be happy to merge it.
>> 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
>