RE: [ECOS] interrupts

[Gary Thomas <gthomas at redhat dot com>]

On Wed, 2002-05-22 at 04:15, Daniel.Andersson@combitechsystems.com
wrote:
> 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.
> 

Have you looked at the relevant code?  (You have the sources!)
Most of this execution path is in hal/powerpc/arch/current/src/vectors.S

Don't forget that eCos is designed to be general.  While it may be true 
that your particular interrupt can be handled in 22us, it can only do so
if a proper environment has been set up.  The vectors.S (the VSR code
actually) is responsible for saving the interrupted environment 
(registers, etc), figuring out to call your ISR (there are many 
interrupt choices, each with it's own ISR), calling your ISR and then,
depending on the return value, possibly setting up to run a DSR later
before returning to the interrupted context.

You've not said much about your platform - MPC850 isn't sufficient
detail.  What about the clock speed? RAM wait states?  I can infer
from your note that the processor can execute approximately 10 
instructions per us.  If you look at the VSR, it's quite plausible
that 100 instructions need to be executed before calling your ISR.
There will be nearly as many required on the way out.  This can be
[somewhat] reduced by enabling CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT.
Also, depending on the configuration, the VSR may call into the kernel
after your ISR for scheduling of possible DSR routines.  This is C/C++
code, and it's very easy to expect it to execute the remaining 200
instructions.

It all makes sense to me (your numbers).  What else is running in your
system?  Are you making use of the kernel, threads, etc?  If so, you
pretty much have to expect some overhead.

Of course, you could always install your own VSR (there is complete
support for this) which tried to be ultra smart in the case of your
one particular interrupt, but that code would still need to be able
to handle other generic interrupts.

> 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



--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss