This is the mail archive of the
mailing list for the eCos project.
Re: Serial Driver Performance Tuning
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: "Haibo Tang (QD/LJC)" <haibo dot tang at ericsson dot com>
- Cc: "'ecos-discuss at sources dot redhat dot com'" <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 11 Feb 2004 04:06:50 +0000
- Subject: Re: [ECOS] Serial Driver Performance Tuning
- References: <0C5B2CD01E65B6458822496C215E8F070686B316@ecnbjnt512.itc.ericsson.se>
Haibo Tang (QD/LJC) wrote:
I am writing a serial driver which support block transfer for ARM. The
baud rate can be 57600 when I layout whole system in SRAM on demo board.
But the destination board is only have 8K or 32K SRAM ( and 2M DRAM). I
must layout most of system on DRAM. The baud rate only can be 19200 in
this case. I try to layout the serial DSR and ISR in the size limited
SRAM, but the serial DSR performance only increase about 10%.
Most of the work is done in the DSR which calls into
io/serial/VERSION/src/common/serial.c (see serial_rcv_char in particular,
or serial_data_rcv_req in block transfer mode).
try to layout some parts of kernel in SRAM. But the address of SRAM and
DRAM is 0x00000000 and 0xd0000000. This cause the "b" instrument can
not be used on ARM when code in SRAM call function in DRAM, and vice
versa. But kernel is C++ program. gcc always generate "b" instrument
for global object constructor no matter if long call compiler option is
Note that the ARM compiler accepts the -mlong-calls option, as well as a
#pragma long_calls directive. See the GCC documentation.
My questions are:
1. Is there other way to increase the performance to support baud rate
This has been a sticking point before. Firstly tune the serial driver
configuration to turn off options you don't need. Secondly, as you've seen
block transfer can be useful. Thirdly, ensure nothing else is hogging the
interrupt system (e.g. by disabling interrupts or DSRs/the scheduler for
too long). Fourthly, worst case, ignore the infrastructure and write yyour
own one - that way it's very much catered to your application requirements,
whereas the eCos driver has to be quite generic and support a range of
Lastly, obviously a big thing you could do is to profile your system to
work out where the time is actually being spent. There is gprof profiler
support in the eCos sources, although I heard a report it doesn't work
(don't take my word for that necessarily - I haven't tried it myself). Also
even if it works it's unable to fully profile the interrupt system and
doesn't count basic blocks, only statistical timer based analysis.
eCosCentric has enhanced profiling support available that can profile the
system more thoroughly. See the URL in my signature or contact me off-list.
This communication is confidential and intended solely for the
addressee(s). Any unauthorized review, use, disclosure or distribution
is prohibited. If you believe this message has been sent to you in
Please don't use things like this in messages to this mailing list. People
who view the online public archives of this mailing list are not
addressees. The administrators of the machine that host this list are
considering blocking access to people with things like this in their mails
due to the possible consequence of them otherwise being deemed to have
broken the law.
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss