Wed May 22 03:15:00 GMT 2002
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
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.
>From: Rafael Rodríguez Velilla [mailto:firstname.lastname@example.org]
>Sent: den 30 maj 2001 12:58
>Subject: Re: [ECOS] interrupts
>> > I`ve a problem with interrupts.I am working on MPC860. I
>> > latecy of handling interrupts (ISR only) and it is very
>> > default configuration in eCos Configuration tool.
>> > Do is it possible to shorten this time, if yes then in
>which way can I do it
>> Same problem exists on my 65 MHz ARM 710T board with 70 nsec
>SRAM, the delay between entering the
>> low-level assembly routine in vectors.S and the actual start
>of my (C) interrupt routine is about 15 micro secs.
>> This means that it takes about 1000 cpu cycles to find out
>which interrupt was fired.
>> There is a lot of overhead involved in retrieving the index
>into the hal_vsr_table.
>> I am thinking of converting the C functions into assembly to
>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
>my system is not well designed, it uses an ARM7TDMI,
>running at 0.8 MHz, but with an 8 bit memory with a WAIT
>state, so every word takes 8 cycles to be read, so the
>number of cycles that I suppose that the system would take
>with a good memory configuration would be just 125
> The place where I loose most of the time is in the
>handle_IRQ routine (or something like that, located at the
>platform HAL), that is the routine that checks which device
>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
More information about the Ecos-discuss