This is the mail archive of the 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: Serial Driver Performance Tuning

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

I also
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
57600 ?

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

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    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: and search the list archive:

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