RE: [ECOS] EDB7312(ARM720T) interrupts

[Gary Thomas <gary@mlbassoc.com>]

On Fri, 2003-11-07 at 15:04, Aaron Case wrote:
> Gary,
> 
> So is the hal_IRQ_handler the function that the OS is vectored to from the
> ARM vector table?
> 
> I ask because I wrote a similar function(as hal_IRQ_handler()) but, haven't
> figured out what is the best way invoke the ISR from the hal_IRQ_handler().
> 
> The interrupt comes in, the processor vectors to 0x18(IRQ for ARM720T) which
> points to hal_IRQ_handler(), which then returns an integer used to invoke
> the appropriate ISR routine for that interrupt.
> 
> Is there a eCos facility for translating the output of the IRQ_handler, or
> do I use this integer as a index into an array of function pointers(pointing
> of course to the ISR's).
> 
> My major concern is that I am minimizing interrupt latency with this scheme.
> 

This is all handled in the interrupt VSR, contained in 
"hal/arm/arch/current/src/vectors.S".  This routine is where the 
hardware "vectors" to when an interrupt occurs.  It performs the
appropriate bookkeeping tasks then calls hal_IRQ_handler to determine
the source of the interrupt.  Once that has been determined, the correct
ISR can be invoked.

The standard VSR takes care of things and should be pretty efficient.
I say "should be" because it is designed to handle things the way eCos
wants them handled in such a way that the same code can work on any ARM
based platform.  I doubt that you can trim it much - and still preserve
the interrupt model that we use with eCos.

> Thanks for the help,
> Aaron Case
> 
> 
> -----Original Message-----
> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, November 07, 2003 4:14 PM
> To: Aaron Case
> Cc: Ecos-Discuss
> Subject: Re: [ECOS] EDB7312(ARM720T) interrupts
> 
> 
> On Fri, 2003-11-07 at 14:01, Aaron Case wrote:
> > Hello,
> >
> > I have a question about implementing interrupts with the rich eCos
> interrupt
> > API with the limited ARM interrupt vector table.
> >
> > >From my experience, and as mentioned in the Massa test, the ARM
> architecture
> > has only two vectors for interrupts(FIQ and IRQ) and the eCos API is
> > implemented more readily for architectures that have multiple entries in
> > their vector tables.
> >
> > It is therefore up to the software to look at the INTSR1/2/3 registers to
> > determine the source of the interrupt.
> >
> > So when I create my 23 different interrupts, where is the most advisable
> > place to decode the source of the interrupt. Ive considered having all the
> > IRQ's share an ISR and each have a unique DSR identifiable through the
> data
> > argument of the cyg_interrupt_create() call.
> >
> > Having all the interrupts share an ISR to decode the interrupt source
> SEEMS
> > to be more processing than the ISR was intended to handle.
> >
> > If the aforementioned approach is not in vogue(or feasible), than could
> > someone out there who has done this before and would be able to point me
> to
> > a post or document that describes how to approach this implementation
> best.
> >
> 
> On the ARM architecture, we assume that your HAL has a function
> "hal_IRQ_handler()" which will interrogate your hardware and return
> a unique value (typically 1..N) indicating which of those interrupts
> has just occurred.  Then there can be a potentially different ISR
> for each interrupt.
> 
> Look at some of the ARM HALs to see how this is done.
> 
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss