This is the mail archive of the ecos-devel@sources.redhat.com 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: 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


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