[ECOS] Interrupts

[ECOS] Interrupts

[Rick Davis]

I am working on a platform with a compact flash. The Compact Flash is
operating in true ide pio mode. I am using the fatfs file system. When I
write a 1.2M file, it takes about 16 seconds to write the file. However, the
eCos clock only advances by 6 seconds. Why is this?
The hardware is a power PC processor using the decrementer as the eCos
clock. I have been trying to find out where, if at all, interrupts are being
disabled while writing the file. Is there anything else that can prevent the
decrementer from operating.
My problem is that I have a watchdog thread strobing a hardware watchdog and
it never runs because the decrementer tics aren't occurring to allow
timeslicing and the unit reboots. The thread priorities are equal and time
slicing is enabled.

Thanks,
Rick Davis



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

RE: [ECOS] Interrupts

[Chris Zimman]

> I am working on a platform with a compact flash. The Compact Flash is
> operating in true ide pio mode. I am using the fatfs file system. When
> I write a 1.2M file, it takes about 16 seconds to write the file. However,
> the eCos clock only advances by 6 seconds. Why is this?
> The hardware is a power PC processor using the decrementer as the eCos
> clock. I have been trying to find out where, if at all, interrupts are
> being disabled while writing the file. Is there anything else that can
> prevent the decrementer from operating.
> My problem is that I have a watchdog thread strobing a hardware
> watchdog and it never runs because the decrementer tics aren't occurring to

> allow timeslicing and the unit reboots. The thread priorities are equal and
> time slicing is enabled.

Hi Rick,

Try instrumenting the macro HAL_DISABLE_INTERRUPTS in
hal/powerpc/arch/[version]/include/hal_intr.h

Maybe something like:

#define HAL_DISABLE_INTERRUPTS(_old_)                   \
    CYG_MACRO_START                                     \
    cyg_uint32 tmp1, tmp2;                              \
    diag_printf("HAL_DISABLE_INTERRUPTS() called from %s at line %d\n",
__FILE__, __LINE__); \
    asm volatile (                                      \
        "mfmsr  %0;"                                    \
        "mr     %2,%0;"                                 \
        "li     %1,0;"                                  \
        "rlwimi %2,%1,0,16,16;"                         \
        "mtmsr  %2;"                                    \
        : "=r"(_old_), "=r" (tmp1), "=r" (tmp2));       \
    CYG_MACRO_END

You should definitely be able to see if/where/when interrupts are being
disabled.

--Chris

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

RE: [ECOS] Interrupts

[Rick Davis]

Chris,

I'll give that a shot.

Thanks for your support and suggestion.
Rick Davis


-----Original Message-----
From: Chris Zimman [mailto:czimman@bloomberg.com] 
Sent: Friday, October 17, 2008 7:41 AM
To: Rick Davis; ecos-discuss@ecos.sourceware.org
Subject: RE: [ECOS] Interrupts

> I am working on a platform with a compact flash. The Compact Flash is
> operating in true ide pio mode. I am using the fatfs file system. When
> I write a 1.2M file, it takes about 16 seconds to write the file. However,
> the eCos clock only advances by 6 seconds. Why is this?
> The hardware is a power PC processor using the decrementer as the eCos
> clock. I have been trying to find out where, if at all, interrupts are
> being disabled while writing the file. Is there anything else that can
> prevent the decrementer from operating.
> My problem is that I have a watchdog thread strobing a hardware
> watchdog and it never runs because the decrementer tics aren't occurring
to

> allow timeslicing and the unit reboots. The thread priorities are equal
and
> time slicing is enabled.

Hi Rick,

Try instrumenting the macro HAL_DISABLE_INTERRUPTS in
hal/powerpc/arch/[version]/include/hal_intr.h

Maybe something like:

#define HAL_DISABLE_INTERRUPTS(_old_)                   \
    CYG_MACRO_START                                     \
    cyg_uint32 tmp1, tmp2;                              \
    diag_printf("HAL_DISABLE_INTERRUPTS() called from %s at line %d\n",
__FILE__, __LINE__); \
    asm volatile (                                      \
        "mfmsr  %0;"                                    \
        "mr     %2,%0;"                                 \
        "li     %1,0;"                                  \
        "rlwimi %2,%1,0,16,16;"                         \
        "mtmsr  %2;"                                    \
        : "=r"(_old_), "=r" (tmp1), "=r" (tmp2));       \
    CYG_MACRO_END

You should definitely be able to see if/where/when interrupts are being
disabled.

--Chris


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

RE: [ECOS] interrupts

[Daniel.Lidsten]

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

RE: [ECOS] interrupts

[Gary Thomas]

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

RE: [ECOS] interrupts

[Geoff Patch]

Hi Guys,

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


If you're going to be receiving interrupts at a *minimum* rate of 5 KHz,
then I think you're right to start thinking about another CPU.

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

We use 50 KHz MPC860s with 4K I and D caches, and my feeling is that a 5 KHz
interrupt would cause real problems for these devices. I believe it's
possible to lock code into the caches (although we've never done it), but
even so, I think you'd still be in trouble.

Just my $0.02, and I'm sorry I can't offer anything more positive.


Good Luck


Geoff

-----------------------------
Geoff Patch
Senior Software Engineer
CEA Technologies
Canberra Australia
02-6213-0141


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

RE: [ECOS] interrupts

[Daniel.Andersson]

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

Re: [ECOS] interrupts

[Andrew Lunn]

On Wed, May 22, 2002 at 12:15:18PM +0200, Daniel.Andersson@combitechsystems.com wrote:
> 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

Can your logic analyzer show you what addresses are being fetched from
RAM? Match that against the symbol table. You can then work out why
its accessing those locations. 

I expect that nearly all the code needed to handle the ISR is not in
cache, unless your processor is not doing anything else. So it will
have to fetch everything in as needed. I doubt there are many loops in
the ISR code, so the cache is actually not giving you much of a
performance boost.

     Andrew

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

RE: [ECOS] interrupts

[Gary Thomas]

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

Re: [ECOS] interrupts

[rob.wj.jansen]

Hm,

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

Thanks for the info.
I guess I'll have to walk through the assembly code to count the cycles, I have to admit that I am a bit confused 
bout the amount of time taken to handle the interrupt. 
Looking at the code most of the time (IMHO) will be lost in the hal_IRQ_handler function which, in my case,
only reads a register from the interrupt controller which returns a byte index in the array. Maybe the time has come
to add an assembly define (#define HAL_PLATFORM_IRQ_HANDLER). In my case a "ldr r1,=ADRRESS; ldr r0,[r1]"
would replace the complete hal_IRQ_handler.

I guess that such a kind of optimization would also be usable for the powerpc platform.

Regards,

	Rob Jansen

Software Engineer
Competence Center Platforms
BU Mobile Communications
Meijhorst 60-10, 6537 KT Nijmegen, The Netherlands
Tel: +31-24-353-6329
Fax: +31-24-353-3613
mailto:Rob.WJ.Jansen@philips.com

Re: [ECOS] interrupts

[rob.wj.jansen]

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

Regards,

Rob Jansen

Sr. Software Engineer
Competence Center Platforms
BU Mobile Communications
Meijhorst 60-10, 6537 KT Nijmegen, The Netherlands
Tel: +31-24-353-6329
Fax: +31-24-353-3613
mailto:Rob.WJ.Jansen@philips.com

Re: [ECOS] interrupts

[Rafael Rodríguez Velilla]

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.

[ECOS] interrupts

[Nicpo&nacute]

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
?

Best regards

Marcin Nicpoń
mailto: nicpon@rts.com.pl
tel. (+48) 602533132