Re: [avrdude-dev] Programmer speed

[Jan-Hinnerk Reichert]

On Wednesday 08 October 2003 07:54, Tom Harris wrote:
> Greetings,
>
> I am using avrdude and the STK500 to program an ATMega 16, and the
> code size is steadily climbing above 8K. Are there any programmers
> that are faster than the STK500, as the wait is getting larger? I
> know that there are programmers that are slower, such as the ones
> based on the appnote no. 910. As an aside, has anyone tried the
> programmers that use the serial port as programmable IO, and drive
> the AVR by bit banging the serial port lines. How are they for
> speed?

There are different factors limiting the programming speed:

1) Write delay

The chip needs some time to write the data to flash. This is real bad 
for the classic AVR (AT90Sxxxx). Impact from write delay is 
significantly lower on ATmega (due to page write).

Nevertheless, some time can be saved by polling, instead of waiting 
the specified programming time. However, polling is not easy to 
implement for SPI programming (there were some strange *features* in 
early classic AVRs and isn't nice for paged writing). So, I wouldn't 
expect any SPI programmer to do this ;-(

Polling is almost for free in Parallel- and Self-programming. It also 
seems to be easy to implement with JTAG. So, you can expect some 
performance gain here. However, flash delay is not that big on 
Atmega.

2) Communication

You need to pass the data to the chip ;-)

a) SPI can be clocked with clk/4. To be on the save side one should 
asume that clk=1MHz (internal oscillator), hence programming can be 
done with 250kBaud at most. For each byte 32 bits need to be 
transfered, this gives an absolute maximum transfer rate of 
7.8Kbyte/s.

If I get the data sheet right, JTAG allows to write the whole page as 
one word. This speeds up data transfer by a factor of almost four. I 
wasn't able to find anything about JTAG clock speed in the datasheet, 
but it could be faster, too.

b) However, it is difficult to generate accurate (and fast) timings 
with a PC parallel port. So, a zero parts programmer will probably be 
much slower.

c) It gets even more complicated, if you have a serial port programmer 
(like AVR910 or STK500). At first every thing looks fine STK500 runs 
at 115.2kBaud, IIRC, hence it gives 11.52kByte/s - that is more than 
the SPI can handle. However, there are additional limits introduced 
by latency.
This is very bad for AVR910 programmers: 2 bytes are sent to the 
programmer, the programmer sents one byte back. After this the UART 
waits an equivalent of 4 bytes, before giving an interrupt request, 
the OS may decide too delay the read even longer.
The STK500 transfers data in greater packages to reduce the effects of 
hardware latency.
Nevertheless, it still introduces some latency, since the whole page 
is first transferred to the programmer and than to the chip (I may be 
wrong here).

d) Latency will most likely increase, if a USB to serial converter is 
used ;-(((

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

Now you can take your datasheet and calculate some times and compare 
them with your measurements. For the ATmega16 I get the following:

Erasing&Programming delays (without polling):
        <0.6s
Data Transfer at 115.2kBaud (without latency and protocol overhead):
        <1.5s
SPI-Transfer (at 1MHz SPI clock, assuming >4MHz system clock):
        <0.6s

Giving a total of less than 3 seconds for programming the whole flash. 
IMHO this is a very optimistic estimate, but it is not impossible...
In theory, it is even possible to bring the time down to 1.5s by 
overlapping transfer and programming ;-)

Now, what are your measured times?

/Jan-Hinnerk