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

[Jan-Hinnerk Reichert]

On Tuesday 18 November 2003 08:53, Theodore A. Roth wrote:
> On Tue, 18 Nov 2003, Jan-Hinnerk Reichert wrote:
> > On Tuesday 18 November 2003 04:36, Brian Dean 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.
> You can also think of it as the maximum time that it takes for the
> internally timed programming operation to complete. If you send
> another prog cmd before the min-delay, the previous prog cmd is
> aborted _if_ it hasn't completed yet. Also note that the duration
> of the internally timed operation varies as a function of Vcc
> (higher Vcc -> faster programming). The programming time can also
> vary from page to page (although not too much).

You are almost right here ;-)
However, the sementics of avrdude's variables is a bit different (from 
the one in Atmel's datasheets):
- max_write_delay is the min-delay at _minimal_ voltage
- min_write_delay is the min-delay at _maximum_ voltage

Since avrdude does not know about the voltage, it has to wait 
max_write_delay.

I just did a grep for min_write_delay, and it seems that it is only 
read once (in my patched version) and that is in a printf statement.

I suggest the following:
- rename max_write_delay to max_write_time
- rename min_write_delay to max_write_time_5V
- consider dropping the later

max_write_time_5V is only useful, if we know that programming voltage 
is 5V. It could be used to calculate the delay for any programming 
voltage like this:
max_write_time(U)=max_write_time_5V*(5V/U)^2
This works for all values I have seen in datasheets. However, it is 
not guarenteed to work.

Considering that polling is used most of the time, I think the speed 
gain is not worth the hassle.

> When polling, what should really happen is something like this
> (psuedo code):

min_delay = max_write_delay ;-)

>   for (timer=0; timer<min_delay; timer += granularity)
>     if (poll() == ready)
>       break;
>     usleep(granularity); // should be maybe 10x smaller than
> min_delay?? }
>
>   if (timer >= min_delay)
>     raise error;

The more I read about usleep() and similar functions, the more I 
believe busy waiting is the right approach here. It is both fast and 
portable. A timeout can easily be detected by gettimeofday() (Is that 
one portable ;-)

/Jan-Hinnerk Reichert