Development Plan Proposal for Unifying Interrupt and PCI APIs

[Joel Sherrill <joel@OARcorp.com>]

gregory.menke at gsfc.nasa.gov wrote:
> Leon Pollak writes:
>  > On Sunday 24 October 2004 12:58, Pavel Pisa wrote:
>  > > is received. Only correct solution is to call all members of chain
>  > > again and again until one full round is not returning no interrupt
>  > > serviced state.
>  > ....and an interrupt fires exactly at the moment when A returned "no interrupt 
>  > serviced"...:-)
> 
> The default Mongoose bsp vectoring code takes this approach, mostly
> because its cheaper to service a bunch of interrupts than to unwind
> the interrupt service routine, then enter it again.  It sort of
> preserves the concept of interrupt priority by scanning the interrupt
> causes in defined if arbitrary priority order.

I must say that I like the MIPS port's solution to vectoring
interrupts.  Every MIPS CPU model has different rules for
decoding 5 bits in the status register.  A port to a new CPU
model is assumed to provide a method with a specific name
to decode those bits and any interrupt controller information
and then dispatch the RTEMS ISR handler.

This allowed the outermost ISR code to be in assembly.  The
CPU model portion can be in assembly but most are in C
because it is easier to read and debug.

> Gregm
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985