This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: interrupts
On Thu, 2002-05-23 at 08:37, Daniel.Lidsten@combitechsystems.com wrote:
> >-----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....?
I can't say. It would depend a lot on what gets to stay in the caches, etc.
I think you should be answering a more fundamental question here; if you are
getting interrupts every 200us (5000/sec), what are you going to be doing
with them? You've not said anything about your application, but it seems to
me that if you have to be doing _anything_ else in this system, you are out
of steam from the get-go. Even if you keep the interrupt [raw] processing
time down to 70us (your original quote), that leaves a scant 130us between
interrupts for the system to be running anything else (threads, etc).
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss