This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: interrupts
- From: Andrew Lunn <andrew dot lunn at ascom dot ch>
- To: Daniel dot Andersson at combitechsystems dot com
- Cc: rrv at tid dot es, ecos-discuss at sourceware dot cygnus dot com
- Date: Wed, 22 May 2002 12:32:06 +0200
- Subject: Re: [ECOS] interrupts
- References: <2253171AF143D21185A60000F8FA748B04840BCB@pluto.combitech.se>
On Wed, May 22, 2002 at 12:15:18PM +0200, Daniel.Andersson@combitechsystems.com wrote:
> 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:
>
> 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
Can your logic analyzer show you what addresses are being fetched from
RAM? Match that against the symbol table. You can then work out why
its accessing those locations.
I expect that nearly all the code needed to handle the ISR is not in
cache, unless your processor is not doing anything else. So it will
have to fetch everything in as needed. I doubt there are many loops in
the ISR code, so the cache is actually not giving you much of a
performance boost.
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