How to Use Interrupts in Applications

[Joel Sherrill]

Robert S. Grimes wrote:
> Hi Joel,
>
> Thanks for the explanation - I've been looking for that for a long
> time!  But of course, good answers so often raise new questions...
>
> Joel Sherrill wrote:
>   
>> 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.
>>     
> I had no idea that this was the real difference!
>   
>> The problem is that the Interrupt Manager was never really intended
>> for high level application use.  It is for BSP and device driver
>> developers.
>>     
> Okay, it sure is primarily of importance to BSP and driver developers,
> but I'm not sure it's wise to say so exclusively.  I know as an
> application developer, it would be great to have all the hardware
> details hidden away, but that's not always practical.  Some devices are
> just too specialized to justify a formal driver, especially with tight
> budgets or special performance requirements.
>   
>> The new or vectored interrupt model needs documentation.
>>     
> Agreed.
>   
>> 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.
>>     
> Understood - I know Thomas has been working rather had on this.  But as
> to your characterization of the PowerPC, I'm not sure I'm convinced -
> please bear with me, but I'm really no PowerPC expert.  However, I do
> know the Xilinx Virtex PowerPC has a number of internal vectors, and at
> the same time, it also an external interrupt that is typically connected
> to an "external" interrupt controller ("external" here means external to
> the PowerPC core, though it is still internal to the Virtex FPGA!). 
> Wouldn't this qualify as a "mixed mode" case?
>   
Yes.  The newer embedded PowerPC's tend to straddle the fence.
The 4xx's the port was done to initially didn't use the
external interrupt for much at all.  The on-CPU peripherals
were more than enough for the initial RTEMS applications.

Then the 6xx RTEMS applications showed up and they
are all external interrupts with multiple layers of bus
structures and interrupt cascading. 

The newer embedded PowerPC's with 603e cores like the
82xx, 52xx, etc seem to straddle the fence.  Many interrupts
can be directly vectored but you still have an external interrupt
with no idea of what is hooked to it until you have a board in
hand.  If it goes to a mezzanine module or bus or..., then the BSP
gets to do some unique vectoring work.

The real idea behind the PIC model is for the BSP to be able
wedge some code into the vectoring logic.  For the directly
vectored interrupts, it doesn't wedge much.  For the PIC
handled cases, it does.

You are right, the name matters.  But the ability to wedge
some BSP specific decode and PIC management code into
the interrupt management scheme is the key feature.  Many
PowerPC models probably have enough on-CPU sources that
you don't need it.  But if you have to get an External Interrupt
and fish, then you need it.

You could also use it to take an interrupt and decode GPIO
inputs and vector something magical yourself. 
>> 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.
>>     
> It's always amazing the power of names, or more precisely, the power of
> poorly chosen names, can have on the understandability of our complex
> systems!  Not a criticism, for we all fall prey to it from time to
> time.  I've spent many hours boring colleagues about what I should call
> something, and still gotten it wrong almost as often as right!  Might I
> suggest we all agree on an appropriate naming and start moving forward? 
> Of course, even that suggestion is difficult.
>   

If you can't name it, then you can't control it.
>> If someone could write up User's Manual suitable documentation for the
>> PIC Interrupt Model, I would be happy to merge it.
>>     
> I'm not sure I'm qualified, but if you get no other takers, I'll
> volunteer - but it'll probably have to wait a while until I get better
> informed through practical experience!
>
>   
That is probably the best time to document it.  When you are
figuring it out. :)

--joel
> Thanks,
> -Bob
>