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

[Brian Dean]

On Mon, Nov 17, 2003 at 11:53:14PM -0800, Theodore A. Roth wrote:

> > > 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 reason for polling is to be faster than that ;-)
> 
> Jan-Hinnerk is right. Brian, I think you have your logic backwards. The
> min-delay is not the min programming time, but the min time before you
> can send the next prog command _if_ you are not polling.

I wasn't objecting or arguing, I was merely answering Jen-Hinerk's
question about why the delay was used because that's how I originally
interpretted the datasheet.  It looked to me that you should wait at
least the min_delay, then poll.  Otherwise wait max_delay.

Upon rereading the datasheets for a few parts, it says to poll to know
when it's OK to write another byte, but in the absence of polling, you
must wait the min time, which depends on VCC.

That's why I mentioned in my last mail that I thought Jan-Hinnerk's
patch, in some form, should go in.  We just need to test it out.  I
might be able to get to it this evening - still up in the air on that.
If you, or Joerg, or Eric get to it sooner, feel free to commit a fix.

I tend to like your patch better - it seems cleaner.  But I think the
net effect is the same: poll until the data reads back correctly but
not to exceed the max wait time.  If the data does not read back
correctly within that time, give up with an error.

Making this logic change should give us a nice boost with parallel
port programmers - perhaps enough to put us on the same order as with
the STK500.

-Brian