Re: [ECOS] Serial Driver Performance Tuning

[Jonathan Larmour <jifl at eCosCentric dot com>]

Haibo Tang (QD/LJC) wrote:
> Hi,
>
> 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
> used.

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
[snip]

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.

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