This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: interrupts
- From: Daniel dot Lidsten at combitechsystems dot com
- To: gthomas at redhat dot com
- Cc: ecos-discuss at sourceware dot cygnus dot com
- Date: Thu, 23 May 2002 16:37:23 +0200
- Subject: RE: [ECOS] interrupts
>-----Original Message-----
>From: Gary Thomas [mailto:gthomas@redhat.com]
>Sent: den 22 maj 2002 16:00
>To: Andersson Daniel
>Cc: rrv@tid.es; ecos-discuss@sourceware.cygnus.com
>Subject: RE: [ECOS] interrupts
>
>
>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.
>
You say that the taskswitch that ia have before i get to my ISR code is
reasonable in time and now that i have examined what's actually happening
than i have to agree. Currently i am experiencing a taskswitch time of ~10us
and since i have such a small cache (2kb instr. and 1kb data in mpc850) then
i dont have any of the relevante code in the caches which means that i have
to make external access to RAM. Such access takes 40ns (burst). This means
that a taskswitch that takes 10us actually executes 250 instruction and i
find that ok.
My problem has at this point elevated to the position where i am unsure of
if the MPC850 is the right CPU choise for this application.
In my application i will receive atleased 5000 interrupt/s which makes the
context switch time a very large part of the systems total capacity. AFAIK
then the VSR code handles _all_ interrupts, is that right? Is there any way
of decreasing the latency on just one interrupt?
I have tried to put the entire VSR handler in dpram to speed up execution
but i only got a 15 percent decrease which of course isnt enough.
Just hypotheoretical - what performance would i get if i used a MPC823 that
has four times that cache size that i have in the MPC850. Could i expect
twice the performance of the 850....?
Regards, Daniel
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss