Re: [avrdude-dev] Bad programming speed on AT90S8535 using AVRdude

[Theodore A. Roth]

On Tue, 18 Nov 2003, Jan-Hinnerk Reichert wrote:

> > The reason us unix guys would prefer the usleep() approach over a
> > busy loop is to free up the cpu for other processes. There's got to
> > be a sane way to do sub-second delays on windows without resorting
> > to a busy loop.
>
> I'm a unix (linux 2.4.23-pre8) guy, too ;-)

Sorry, I thought you were using windows.

> I understand the problem (I feel it every time I use cdrdao). However,
> I think programming should be fast.
>
> Perhaps it is best to make some speed tests first. If busy-waiting
> does not give a significant gain there is no need for further
> discussion.
>
> BTW: Perhaps we could use sched_yield() to make it behave better.

That's possible.

>
> [some URL]
> > He's saying that gettimeofday() is a bit too course grained.
>
> This shouldn't be a problem here: gettimeofday() is only used to
> determine if the write has failed.
>
> Pseudo-Code:
> if (polling_is_OK)
>   do {
>      poll
>   } while (!ready) && (!timed_out)
>
> Since there is no timeout in normal operation, the timeout can be much
> larger than max_write_delay.
>
> > The more I read about this, the more I think that select() is the
> > best way to get sub-second timing delays. There is this wart on
> > linux though:
>
> Under FreeBSD usleep() is using select(), under Linux it is using
> nanosleep().
>
> I think there is still the same granularity issue with select() under
> Linux ;-(

Ok. I just did some tests on my linux box.

$ uname -a
Linux knuth 2.4.18-386 #2 Sun Apr 14 10:38:08 EST 2002 i686 GNU/Linux

Programming a mega128 with a 32052 byte srec file with this command:

  $time ./avrdude -p atmega128 -c stk200 -e -V -v -i dlogr.srec

latest cvs:                        21.798 s
with Jan-Hinnerk's patch:          22.503 s
same with s/1000/100/ in loop:     21.799 s
same with s/1000/10/:              22.213 s

I then changed the inner loop to this:

    else {
      gettimeofday (&tv, NULL);
      start_time = (tv.tv_sec * 1000000) + tv.tv_usec;
      do {
        /*
         * Do polling, but don't wait (much) longer than max_write_delay
         * Granularity might need some tuning for best performance.
         */
        rc = avr_read_byte(pgm, p, mem, addr, &r);
        if (rc != 0) {
          pgm->pgm_led(pgm, OFF);
          pgm->err_led(pgm, ON);
          return -4;
        }
        gettimeofday (&tv, NULL);
        prog_time = (tv.tv_sec * 1000000) + tv.tv_usec;
      } while ((r != data) &&
               ((prog_time-start_time) < mem->max_write_delay));

and the time was 21.050 seconds. (patch attached for reference)

Just for grins:

   avrdude to stk500 took 12.306 seconds.

For more grins:

   avarice to jtagice took 12.238 seconds.

Looks to me like we may already be doing the best we can do considering
that we are basically bit-banging the SPI interface on the SPI port. Has
anyone run the numbers to see what the theoretical max speed for this
is?

I doubt that we could get close to what the jtagice box and the stk500
are doing. (I don't have any data to back up that claim though ;-)

Ted Roth