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

[idefixx]

> My guess is that, at around 40% through your code, you have a lot of
> zero-valued data, ...
Yer! You're right!

> ..., try setting 'readback_p2' to 0xff (same as readback_p1) and
> see if that helps or eliminates the problem.
Yes, thanks, that helped ! The programming time now decreased from 92sec to 
41sec.   :-)

I was watching the command output with -v -v option and found out that my 
statement from yesterday was not completely correct. As it seems, the 
programming works like that (when using the original 0x00 value for 
readback_p2):
A) In the area of program code (the first 40%):
   1) Read Program Memory (high or low read)
   2) Write Program Memory (high or low)
   3) Read Program Memory (high or low) - this I guess is the polling
   4) But now it waits for min_write_delay (4000us)
   5) continued with 1)

B) In the area of zeros:
   1) Read Program Memory (high or low)
   2) Write Program Memory (high or low)
   3) Read Program Memory (high or low)
   4) Wait for min_write_delay (4000us)
   5) Read Program Memory (high or low) again - I don't know why
   6) Wait for max_write_delay (9000us)
   7) continued with 1)

Changing readback_p2 value to 0xFF helped that the entire programming process 
runs as described in A) and therefore the programming time was massively 
reduced. But still there is the delay mentioned in A.4 - What for? For interest 
I reduced the min_write_delay value to 200us (for roughly simulating the delay 
of a polling in A.4). That helped reducing the programming time from 41sec to 
28 sec. This is the same time as the STK500 board needs to program the 
AT90S8535. Do you have a clue, what this delay in A.4 is for? Couldn't this be 
removed, as far as in A.3 polling is done with the reading command anyway?

/idefixx