From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2238 invoked by alias); 14 Nov 2003 22:08:04 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 2230 invoked from network); 14 Nov 2003 22:08:02 -0000 Received: from unknown (HELO mail.dynazign.com) (66.0.244.3) by sources.redhat.com with SMTP; 14 Nov 2003 22:08:02 -0000 Received: from aaronc [66.0.244.2] by mail.dynazign.com with ESMTP (SMTPD32-7.07) id AF9E5890078; Fri, 14 Nov 2003 16:56:46 -0500 From: "Aaron Case" To: "Gary Thomas" Cc: "Ecos-Discuss" Date: Fri, 14 Nov 2003 22:08:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal Importance: Normal In-Reply-To: <1068246045.6577.55.camel@hermes> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: RE: [ECOS] EDB7312(ARM720T) interrupts X-SW-Source: 2003-11/txt/msg00215.txt.bz2 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 > MLB Associates -- Gary Thomas 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