* [ECOS] EDB7312(ARM720T) interrupts @ 2003-11-07 21:01 Aaron Case 2003-11-07 21:14 ` Gary Thomas 0 siblings, 1 reply; 11+ messages in thread From: Aaron Case @ 2003-11-07 21:01 UTC (permalink / raw) To: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] EDB7312(ARM720T) interrupts 2003-11-07 21:01 [ECOS] EDB7312(ARM720T) interrupts Aaron Case @ 2003-11-07 21:14 ` Gary Thomas 2003-11-07 22:05 ` Aaron Case 0 siblings, 1 reply; 11+ messages in thread From: Gary Thomas @ 2003-11-07 21:14 UTC (permalink / raw) To: Aaron Case; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-07 21:14 ` Gary Thomas @ 2003-11-07 22:05 ` Aaron Case 2003-11-07 23:00 ` Gary Thomas 0 siblings, 1 reply; 11+ messages in thread From: Aaron Case @ 2003-11-07 22:05 UTC (permalink / raw) To: Gary Thomas; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-07 22:05 ` Aaron Case @ 2003-11-07 23:00 ` Gary Thomas 2003-11-14 22:08 ` Aaron Case 0 siblings, 1 reply; 11+ messages in thread From: Gary Thomas @ 2003-11-07 23:00 UTC (permalink / raw) To: Aaron Case; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-07 23:00 ` Gary Thomas @ 2003-11-14 22:08 ` Aaron Case 2003-11-14 22:13 ` Andrew Lunn 0 siblings, 1 reply; 11+ messages in thread From: Aaron Case @ 2003-11-14 22:08 UTC (permalink / raw) To: Gary Thomas; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] EDB7312(ARM720T) interrupts 2003-11-14 22:08 ` Aaron Case @ 2003-11-14 22:13 ` Andrew Lunn 2003-11-14 22:22 ` Aaron Case 2003-11-17 15:57 ` Aaron Case 0 siblings, 2 replies; 11+ messages in thread From: Andrew Lunn @ 2003-11-14 22:13 UTC (permalink / raw) To: Aaron Case; +Cc: Gary Thomas, Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-14 22:13 ` Andrew Lunn @ 2003-11-14 22:22 ` Aaron Case 2003-11-14 23:08 ` Gary Thomas 2003-11-17 15:57 ` Aaron Case 1 sibling, 1 reply; 11+ messages in thread From: Aaron Case @ 2003-11-14 22:22 UTC (permalink / raw) To: Andrew Lunn; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-14 22:22 ` Aaron Case @ 2003-11-14 23:08 ` Gary Thomas 0 siblings, 0 replies; 11+ messages in thread From: Gary Thomas @ 2003-11-14 23:08 UTC (permalink / raw) To: Aaron Case; +Cc: Andrew Lunn, Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-14 22:13 ` Andrew Lunn 2003-11-14 22:22 ` Aaron Case @ 2003-11-17 15:57 ` Aaron Case 2003-11-17 16:02 ` Gary Thomas 1 sibling, 1 reply; 11+ messages in thread From: Aaron Case @ 2003-11-17 15:57 UTC (permalink / raw) To: Andrew Lunn; +Cc: Ecos-Discuss, gary 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-17 15:57 ` Aaron Case @ 2003-11-17 16:02 ` Gary Thomas 2003-11-17 16:48 ` Aaron Case 0 siblings, 1 reply; 11+ messages in thread From: Gary Thomas @ 2003-11-17 16:02 UTC (permalink / raw) To: Aaron Case; +Cc: Andrew Lunn, Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] EDB7312(ARM720T) interrupts 2003-11-17 16:02 ` Gary Thomas @ 2003-11-17 16:48 ` Aaron Case 0 siblings, 0 replies; 11+ messages in thread From: Aaron Case @ 2003-11-17 16:48 UTC (permalink / raw) To: Gary Thomas; +Cc: Ecos-Discuss 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-11-17 16:48 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-11-07 21:01 [ECOS] EDB7312(ARM720T) interrupts Aaron Case 2003-11-07 21:14 ` Gary Thomas 2003-11-07 22:05 ` Aaron Case 2003-11-07 23:00 ` Gary Thomas 2003-11-14 22:08 ` Aaron Case 2003-11-14 22:13 ` Andrew Lunn 2003-11-14 22:22 ` Aaron Case 2003-11-14 23:08 ` Gary Thomas 2003-11-17 15:57 ` Aaron Case 2003-11-17 16:02 ` Gary Thomas 2003-11-17 16:48 ` Aaron Case
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).