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

[Brian Dean]

On Tue, Nov 18, 2003 at 04:26:30AM +0100, Jan-Hinnerk Reichert wrote:

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

I have an STK200 that I've been using lately and will try it when I
get a chance.  I thought I'd be able to test it out this evening, but
other things have gotten in the way.

The reason it always waits at least the min_delay is that, well,
that's the minimum programming time according to the data sheet :-)
The effectiveness of your patch will depend on the granularity of the
usleep() call.  I expect that its effectiveness will vary depending on
what OS is being used, and possibly can be tuned, i.e., in FreeBSD I
think we can set the kernel HZ value higher to get finer timing
resolution, but I'll have to check on that.  Linux probably has
something similar.

Thanks for the patch - it should help, once we get it tested.

Cheers,
-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/