This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: RedBoot load command speedup
- From: Larice Robert <larice at vidisys dot de>
- To: jeroen dobbelaere <jeroen dot dobbelaere at acunia dot com>
- Cc: ecos-devel at sources dot redhat dot com
- Date: Mon, 1 Jul 2002 16:17:51 +0200 (CEST)
- Subject: Re: RedBoot load command speedup
Hello, Jeroen Dobbelaere
did you actually experience the
CYGACC_CALL_IF_DELAY_US(2*100000);
i thought this won't be called frequently, but i'm actually much to
lazy to read and understand all this stuff.
i'd think to download 32Mbyte with redboot is just kind of misuse of
redboot. redboot is designed to be simple. its one of the first thing you
have to port if you are targeting a new platform. And then you are glad
if you don't have to bother wit irq controllers (for timers and for
network chips) for this reason ecos developer obviously chose this
polling stuff. thus in your case i'd compile something similar as
redboot, but with the real HAL, (with interrupt driven network io,
with interrupt driven timebase etc).
this MS_TICKS stuff is obviously meant to maintain some kind of rudimentary
timebase, when there is actually none. (the idea of timebase is necessary
for various net protocols, timeouts ...) simply shortening those delays
will damage slow target machines. (those would have their time running
more slowly, because the cpu-time per call to hal_delay_us would be worse)
what could be done without much rising the hardware prerequisites,
is to have a more sophisticated hal_delay_us.
one which keeps running/circling in the background (without interrupts).
i suppose most targets could be configured for some kind of free-running
counter easily. instead of doing something like
for(500) {
trysomething();
hal_delay_us(1000);
}
one would then to something like
int t = hal_rudimentary_time_get();
t = hal_rudimentary_time_add(t,500000);
while(!hal_rudimentary_endofgame(t)) {
trysomething();
}
so you wouldn't destroy concept of time by slow cpu processing, and
you would poll as frequently as the machine actually can.
> Hi all,
>
> I am experimenting with an xscale platform with a smc91c111 ethernet chip.
>
> By using appended patch, I am able reducing the time to
> download 32MByte (tftp) from >4 minutes to 20 seconds.
> (Which becomes acceptable)
>
> I think reducing those delay values _is_ important.
>
> Greetings,
> --
> Jeroen Dobbelaere
> Embedded Software Engineer