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

[Jan-Hinnerk Reichert]

On Tuesday 18 November 2003 22:35, Theodore A. Roth wrote:
> On Tue, 18 Nov 2003, Jan-Hinnerk Reichert wrote:

> 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

Hi Ted,

perhaps a atmega128 is not the best candidate for the test ;-)))

If I'm not mistaken the code in question is _never_ hit during 
programming a paged memory.

The delay takes place in avr_write_page() and it is just a simple:
usleep(max_write_delay);

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

Looks like the patch I thought off ;-)

> 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 have calculated some numbers from your data:

Number of pages: 126
Total write delay: 567ms
Even with a very bad sleep, this should be no longer than 3s

Time for writing a page with parallel port: approx 175ms
Time for transfering data: 160-175ms
SCK cycles per page: 257*32
SCK frequency: 47-50kHz

So the problem for _paged_ memory is the SPI-transfer-speed.

The theoretical max-speed depends on the target clock speed (if 
known). If we asume a 1MHz target clock (internal RC), SCK can be up 
to 250kHz (only with symmetric clock).
This gives a theoretical minimum of 4.7 seconds for your example.

------------------------

While we are at it, I have looked into par.c and ppi.c
A single bit on the SPI takes 7 ioctl()-calls (4 get and 3 set)
Required are only 4 (1 get and 3 set).

About a speedup like this one.

int shadow_ioctl (int fd, int request, unsigned char &v) {
  static unsigned char shadow[SOME_VALUE];

  if (request == shadow_get) {
    v = shadow[WHATEVER];
    return 0;
  }

  ioctl(d, request, &v);
  shadow[WHATEVER]=v;
  return 0;
}

I better stop for now. I start getting slow ;-)

/Jan-Hinnerk