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

[Jan-Hinnerk Reichert]

On Wednesday 19 November 2003 07:33, Theodore A. Roth wrote:
> On Wed, 19 Nov 2003, Jan-Hinnerk Reichert wrote:
> > On Tuesday 18 November 2003 22:35, Theodore A. Roth wrote:
> > > On Tue, 18 Nov 2003, Jan-Hinnerk Reichert wrote:

> Ok, I've re-done my tests with a 8515. Here are the results:
>
> Test file is 7782 bytes (attached for those interested).
>
> latest cvs (no patches)         2m36.5 s
>
> with Jan-Hinnerk's patch (delay in inner loop):
>   (1000 us delay):              2m36.2 s
>   (100 us delay):               2m36.2 s
>   (1 us delay):                 2m36.3 s
>
> Then I replaced usleep() with select():
>   (2000 us delay):              1m18.6 s
>   (100 us delay):               1m18.6 s
>   (10 us delay):                1m18.6 s
>
> Then with my gettimeofday() mod to Jan-Hinnerk's patch:
>                                 25.269 s

Amazing how the numbers fit ;-)
udelay() gives exactly 20ms per byte, select() gives 10ms.

The programming time of the last version is 3.20ms per byte, which is 
way below the max_delay of 4.5ms ;-)))

The 3.20ms are (approx.) a multiple of the time needed for one SPI 
command. From the numbers, you gave in your mega128 test, I would say 
640us*5 (1 read + 1 write + 3 poll). Could you please verify the 
number of polls using "-v -v" option (just curious).

So it is less than 2ms write-delay. From the 1.2ms needed for first 
two commands, we can save approx 0.5ms using shadow registers in 
"ppi.c" (like I mentioned in my last post).

This is not of much significance for unpaged memory, but should save 
more than 40% programming time for paged memory devices ;-)))

I'm working on this one. Perhaps I should build a parallel cable to be 
able to test this stuff ;-(

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

Two more notes to the patch:
- the comment about tuning granularity should be dropped
- max_write_delay is *signed*  integer, this makes me feel a bit 
uneasy about the loop termination

/Jan-Hinnerk