Re: [avr-chat] Dragon: mega slow at dumping Flash, normal ?

[Rogier Wolff]

On Mon, Jun 29, 2009 at 11:07:12AM +0930, Daniel O'Connor wrote:
> > Yeah but it's very fast with my crappy // port DIY cable ('bsd'
> > style), it's only when using my Dragon that somehow terminal mode
> > becomes super slow. That's why I am trying to find out if it's
> > because of the Dragon that's crap (sorry Atmel) or if the terminal
> > mode somehow has some bug that makes it slow with the Dragon, but
> > fast with a DIY cable. I still have not been able to figure out which
> > of the Dragon or avrdude, is at fault... so I can't take action ! ;-)
> 
> The Dragon is slow because there is a lot more protocol overhead, so 1 
> byte at a time transfers are very wasteful.

The crappy DIY parallel cable requires a couple of IO instructions,
for every bit transferred. An IO instruction to a parallel port takes,
even on a modern computer, about a microsecond. So you'll get about 1
million divided by N bits per second of tranfer speed on your DIY
cable. N is the number of IO instructions required, two or three.

The way USB is built, you can only send or recieve stuff at 1kHz rate.
(i.e. there is a slot you can use (or not) every ms.) Thus if for
example you read a disk drive one block at a time, you'll get exactly
1000 blocks per second. (my measurements indicate somewhere between
999.9 and 1000.1 well within measurement errors)...

Anyway, if you have an USB device, and require some protocol overhead
for every byte, then you'll easily incur an "almost 1ms" delay for
everything you do. This could easily make some stuff 1000x slower than
the direct IO approach.... 

If the dragon is a serial device, sending a byte at 19k2 requires
about half a ms, and the same applies....

I have an AVR development board, and it can be programmed
out-of-the-box over the USB. However this is SLOW! it takes around 45
minutes to program the "you're an STK500 now" program in
there. Luckily I had to do this only once. :-) (except for debugging
the STK500 firmware).

This is due to the multiple 1ms delays that occur for every
bit. Optimizing my programming methods could be done, however this
isn't easily applied to the AVDUDE source: AVRDUDE assumes that it can
examine the resulting shifted-out bits immediately after sending a
byte. The way to optmize such programming through the FTDI232 chip is
to set the bitbang bitrate on the FTDI and just send it a block of
data. The FTDI can then send back the resulting bitstream. You can
achieve very high bitrates using this technique, but the returning
bits can only be sampled/checked after sending a whole block of data.

Anyway, I have my own STK500 now... :-)

        Roger. 

-- 
** address@hidden ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement. 
Does it sit on the couch all day? Is it unemployed? Please be specific! 
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ