From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30031 invoked by alias); 22 May 2002 10:15:11 -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 30010 invoked from network); 22 May 2002 10:15:07 -0000 Received: from unknown (HELO venus.combitech.se) (146.75.247.84) by sources.redhat.com with SMTP; 22 May 2002 10:15:07 -0000 Received: from pluto.combitech.se (localhost [127.0.0.1]) by venus.combitech.se (8.11.6/8.11.6) with ESMTP id g4MAF3e08830; Wed, 22 May 2002 12:15:04 +0200 (MEST) Received: by pluto.combitech.se with Internet Mail Service (5.5.2650.21) id ; Wed, 22 May 2002 12:15:21 +0200 Message-ID: <2253171AF143D21185A60000F8FA748B04840BCB@pluto.combitech.se> From: Daniel.Andersson@combitechsystems.com To: rrv@tid.es, ecos-discuss@sourceware.cygnus.com Date: Wed, 22 May 2002 03:15:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECOS] interrupts X-SW-Source: 2002-05/txt/msg00251.txt.bz2 Hi, I read our below posting and was wondering if you maybe have come to a solution with our long ISR startup time? Currently i have almost the same problem on my MPC850. Everytime i receive an interrupt then i get the following timeschedule:=20 0 -10us I can see a lot of RAM access - dont know what it is but i assume that the SW investigate what caused the interrupt 10-32 I enter my isr which is 250 asm instruction (it takes 22us) 32-70 The code exits the ISR and starts doing some other SW processing that i dont know what it is. However, i can see a lot of RAM access after that i have left the ISR but My question is: What can cause my CPU to execute this slow? The ISR, which is 250 instruction, takes 22us and that can be reasonable. I have looked at the caches but find them to be working - as far as i can tell at leased. Regards, Daniel >-----Original Message----- >From: Rafael Rodr=EDguez Velilla [mailto:rrv@tid.es] >Sent: den 30 maj 2001 12:58 >To: ecos >Subject: Re: [ECOS] interrupts > > >rob.wj.jansen@philips.com wrote: > >> > I`ve a problem with interrupts.I am working on MPC860. I=20 >measured time >> > latecy of handling interrupts (ISR only) and it is very=20 >long time.I`ve >> > default configuration in eCos Configuration tool. >> > Do is it possible to shorten this time, if yes then in=20 >which way can I do it >> >> Same problem exists on my 65 MHz ARM 710T board with 70 nsec=20 >SRAM, the delay between entering the >> low-level assembly routine in vectors.S and the actual start=20 >of my (C) interrupt routine is about 15 micro secs. >> This means that it takes about 1000 cpu cycles to find out=20 >which interrupt was fired. >> There is a lot of overhead involved in retrieving the index=20 >into the hal_vsr_table. >> I am thinking of converting the C functions into assembly to=20 >speed up interrupt handling (with the penalty >> that I'm not compatible with the rest of the world anymore. > > In my system it only takes 1000 cycles to start the ISR, but=20 >my system is not well designed, it uses an ARM7TDMI, >running at 0.8 MHz, but with an 8 bit memory with a WAIT=20 >state, so every word takes 8 cycles to be read, so the >number of cycles that I suppose that the system would take=20 >with a good memory configuration would be just 125 >cycles. > > The place where I loose most of the time is in the=20 >handle_IRQ routine (or something like that, located at the >platform HAL), that is the routine that checks which device=20 >has raised the IRQ. I think that eCos has a good >performance with the IRQs and maybe you should optimise that routine. > > > > -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss