[ECOS] EDB7312(ARM720T) interrupts

[ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

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.

Thanks in advance,
Aaron Case



Aaron Case
Dynazign, Inc.
Charlotte, NC


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

Re: [ECOS] EDB7312(ARM720T) interrupts

[Gary Thomas]

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


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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

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.

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



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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Gary Thomas]

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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

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

Re: [ECOS] EDB7312(ARM720T) interrupts

[Andrew Lunn]

On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> 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 don't see anywhere in your code where you program the serial chip to
actually enable it to generate interrupts. Also, does eCos provide a
serial driver for this chip? If so, that driver may already have the
interrupt.

        Andrew

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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

Andrew,

The interrupt named in the cyg_interrupt_create() call is from the
hal_platform_ints.h file and is an onboard UART to the ARM 720T core of the
EDB7312 microprocessor. To my knowledge all that is needed is to program the
syscon1 register to enable UART1 and to enable interrupts.  I have verified
this is done by the eCos system startup routines with my ICE.

Is there something else that I am missing??

Thanks,
Aaron

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Friday, November 14, 2003 5:13 PM
To: Aaron Case
Cc: Gary Thomas; Ecos-Discuss
Subject: Re: [ECOS] EDB7312(ARM720T) interrupts


On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> 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 don't see anywhere in your code where you program the serial chip to
actually enable it to generate interrupts. Also, does eCos provide a
serial driver for this chip? If so, that driver may already have the
interrupt.

        Andrew


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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Gary Thomas]

On Fri, 2003-11-14 at 15:22, Aaron Case wrote:
> Andrew,
> 
> The interrupt named in the cyg_interrupt_create() call is from the
> hal_platform_ints.h file and is an onboard UART to the ARM 720T core of the
> EDB7312 microprocessor. To my knowledge all that is needed is to program the
> syscon1 register to enable UART1 and to enable interrupts.  I have verified
> this is done by the eCos system startup routines with my ICE.
> 
> Is there something else that I am missing??

Try looking at the serial I/O drivers for this platform.  They use 
interrupts and work just fine, so the answers you seek will be there.
  devs/serial/arm/edb7xxx/

> 
> Thanks,
> Aaron
> 
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, November 14, 2003 5:13 PM
> To: Aaron Case
> Cc: Gary Thomas; Ecos-Discuss
> Subject: Re: [ECOS] EDB7312(ARM720T) interrupts
> 
> 
> On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> > 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 don't see anywhere in your code where you program the serial chip to
> actually enable it to generate interrupts. Also, does eCos provide a
> serial driver for this chip? If so, that driver may already have the
> interrupt.
> 
>         Andrew
-- 
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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

Hello,

For purposes of updating the list I see now why it didnt work. I used the
interrupt vector instead of the handle in the cyg_interrupt_attach() call.
Refer to the bogus code I posted in the previous listing. Opps.

thanks,
Aaron Case

-----Original Message-----
From: Andrew Lunn [mailto:andrew@lunn.ch]
Sent: Friday, November 14, 2003 5:13 PM
To: Aaron Case
Cc: Gary Thomas; Ecos-Discuss
Subject: Re: [ECOS] EDB7312(ARM720T) interrupts


On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> 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 don't see anywhere in your code where you program the serial chip to
actually enable it to generate interrupts. Also, does eCos provide a
serial driver for this chip? If so, that driver may already have the
interrupt.

        Andrew


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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Gary Thomas]

On Mon, 2003-11-17 at 08:57, Aaron Case wrote:
> Hello,
> 
> For purposes of updating the list I see now why it didnt work. I used the
> interrupt vector instead of the handle in the cyg_interrupt_attach() call.
> Refer to the bogus code I posted in the previous listing. Opps.
> 

I'm curious how you found this?  by inspection?  did you try enabling
asserts?

> thanks,
> Aaron Case
> 
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, November 14, 2003 5:13 PM
> To: Aaron Case
> Cc: Gary Thomas; Ecos-Discuss
> Subject: Re: [ECOS] EDB7312(ARM720T) interrupts
> 
> 
> On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> > 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 don't see anywhere in your code where you program the serial chip to
> actually enable it to generate interrupts. Also, does eCos provide a
> serial driver for this chip? If so, that driver may already have the
> interrupt.
> 
>         Andrew
-- 
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

RE: [ECOS] EDB7312(ARM720T) interrupts

[Aaron Case]

inspection and a little pedantry

-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Monday, November 17, 2003 11:02 AM
To: Aaron Case
Cc: Andrew Lunn; Ecos-Discuss
Subject: RE: [ECOS] EDB7312(ARM720T) interrupts


On Mon, 2003-11-17 at 08:57, Aaron Case wrote:
> Hello,
>
> For purposes of updating the list I see now why it didnt work. I used the
> interrupt vector instead of the handle in the cyg_interrupt_attach() call.
> Refer to the bogus code I posted in the previous listing. Opps.
>

I'm curious how you found this?  by inspection?  did you try enabling
asserts?

> thanks,
> Aaron Case
>
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: Friday, November 14, 2003 5:13 PM
> To: Aaron Case
> Cc: Gary Thomas; Ecos-Discuss
> Subject: Re: [ECOS] EDB7312(ARM720T) interrupts
>
>
> On Fri, Nov 14, 2003 at 05:07:29PM -0500, Aaron Case wrote:
> > 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 don't see anywhere in your code where you program the serial chip to
> actually enable it to generate interrupts. Also, does eCos provide a
> serial driver for this chip? If so, that driver may already have the
> interrupt.
>
>         Andrew
--
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