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


>-----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


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