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

[Brian Dean]

On Tue, Nov 18, 2003 at 01:35:52PM -0800, Theodore A. Roth wrote:

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

Dang, I really thought it would help, especially if we avoid the
usleep() call entirely, since then we are usually constrained by the
granularity of an OS timer which can be upwards of several ms (10's
even) in the case of a scheduling timer.

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

Can you e-mail me your srec file that you are using?  I'd like to try
the same test under FreeBSD and see its results.  I would expect
similar, but I'd like to try it and see.

> Just for grins:
> 
>    avrdude to stk500 took 12.306 seconds.
> 
> For more grins:
> 
>    avarice to jtagice took 12.238 seconds.

Yes - I've observed similar timings in the past, that the STK500 seems
to program around twice as fast.  I was under the impression that the
JTAGICE was even faster, but I never actually measured the speed since
I usually only use it infrequently when I'm debugging some hairy code.

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

Ultimately, the bit banging results in 'in' and 'out' instructions
being executed on the parallel port data and control registers.  I
don't know how fast those execute on a modern PC.  Aren't they limited
to ISA bus speed specs, I thought, something like 8 MHz or something
like that?

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

The hardware devices like the STK500 have much better control over the
process since they don't have to worry about task switching, TCP/IP
stacks, disks, and process scheduling fairness ;-)

-Brian