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

[Jan-Hinnerk Reichert]

On Tuesday 18 November 2003 02:10, idefixx wrote:
> 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)

IMHO you get the order wrong. It should be: 1 2 4 3 

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

Again it is: 1 2 4 3 6 5

In A1) and B1) the byte is read. If it is equal to the desired value 
nothing else is done. So 0xFF is almost skipped.

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

Just removing the usleep is likely to fail, because the "tries" are 
exceeded fast. Please try the patch I posted earlier this day 
(actually yesterday ;)

It removes B4 and B3 and decreases the delay in A4.

Also experiment with the usleep value in the patch. Unfortunatly, I 
don't have a parallelport-prommer, so I can't test it myself.

/Jan-Hinnerk