RE: [ECOS] EDB7312(ARM720T) interrupts

["Aaron Case" <aaron dot case at dynazign dot com>]

Gary,

Many thanks, that cleared up my understanding of eCos interrupts a great
deal.  Although, I still cant seem to achieve software connectivity with the
eCos interrupt model.

While testing my interrupt code I have observed that I can assert bits in
the interrupt status register by sending characters to a UART. As well as
enabling them with cyg_interrupt_unmask() call(see below).

I, however, have not be able to get the ISR(and thus DSR) to execute(via
break points with my MAJIC ICE).

In the case of the UART1 RX interrupt, I can send a character, verify its
arrival at the buffer and FIFO, but no ISR or DSR is executed. Im assuming
the problem is my software configuration(which is REALLY close to the Massa
text).  See code below.

I was able to accomplish this task with my own code, but would MUCH RATHER
have eCos working instead.

This is the code for cyg_user_start...
cyg_interrupt_create(	CYGNUM_HAL_INTERRUPT_URXINT1,
				int1_priority,
				0,
				&interrupt_1_isr,
				&interrupt_1_dsr,
				&int1_handle,
				&int1);

	//attach the interrupt created to the vector
	cyg_interrupt_attach( CYGNUM_HAL_INTERRUPT_URXINT1 );

	//unmask the interrupt the we just configured.
	cyg_interrupt_unmask( CYGNUM_HAL_INTERRUPT_URXINT1 );

Here is my ISR...
cyg_uint32 interrupt_1_isr(cyg_vector_t vector, cyg_addrword_t data)
{

	//block this interrupt from occuring until after the dsr has finished.
	cyg_interrupt_mask(vector);

	//tell the processor that we have recieved the interrupt
	cyg_interrupt_acknowledge( vector );

	//tell the kernel that the dsr needs to executed
	//next
	return( CYG_ISR_CALL_DSR );

}
and here is the DSR...
void interrupt_1_dsr(
					cyg_vector_t vector,
					cyg_ucount32 count,
					cyg_addrword_t data)
{
	//this DSR contians code to process the incoming characters
	.
	.
	.

	//allow this interrupt to occur again.
	cyg_interrupt_unmask( vector );

}



-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Friday, November 07, 2003 6:01 PM
To: Aaron Case
Cc: Ecos-Discuss
Subject: RE: [ECOS] EDB7312(ARM720T) interrupts


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