This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: interrupts


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: 

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íguez 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 
>measured time
>> > latecy of handling interrupts (ISR only) and it is very 
>long time.I`ve
>> > 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
>cycles.
>
>  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]