Hi Harry,
Harry Gunnarsson wrote:
Thanks Greg. Perfect, a pointer in the right direction helps a lot.
Just one quick followup;
In your opinion, given the 60Mhz clock on our M5272 CPU, does the
interrupt latency sound in the right ballpark to you?
I can't say I have ever closely looked at the exact latency times.
So I am not sure.
Note that by using a level 7 interrupt on the ColdFire you
effectively are using an NMI. So you can expect latency as
good as the hardware can deliver. The down side of using a
level 7 interrupt is that you need to carefully craft your
interrupt handler (and you cannot use linux primitives in it
- you are bypassing all kernel locking).
Regards
Greg
On Nov 21, 2007 4:04 PM, Greg Ungerer <[EMAIL PROTECTED]> wrote:
Hi Harry,
Harry Gunnarsson wrote:
Hi everybody,
I am running uClinux on a custom board with the following configuration
- 20070131 distro with 2.6.22.6 <http://2.6.22.6> kernel
- M5272 CPU clocked at 60MHz (not 66..)
- Compiled with CodeSourcery 4.2-47
- Custom board has serial port, RJ45 ethernet
Essentially, our application only has one real-time requirement,
everything else is more of a control nature where there is no real time
constraints. The real-time event is served with an interrupt as
- Interrupt line hooked up to ext 3
- priority 5
- request_irq called with SA_INTERRUPT
We did some profiling on this interrupt and with a extremely stripped
down driver for the interrupt we see the following numbers
- 12.5 microsecond latency from interrupt line is pulled until service
routine is getting called.
If my arithmetic skills serve me right, that's 750 clock cycles.
Questions:
- Does this sound slow? Is this the latency you'd expect from a system
above?
- Does anyone else have any other interrupt performance stats for
ColdFire that he/she wants to share?
- Is there any way one can speed up the handling of an interrupt without
re-inventing linux?
One approach is to directly handle interrupts in your driver code,
and bypass the standard Linux interrupt handling entry/exit code.
But you do need to be very careful with what you do in your "fast"
interrupt handler.
As an example of how this might work look at the 5249 audio
driver in the linux-2.4.x/drivers/char/m5249audio.c. It bypasses
the linux interrupt handling, and uses its own assembler version
of an interrupt routine (specifically to get low latency).
Regards
Greg
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing Corporation PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
