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

[Theodore A. Roth]

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

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

  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;



Ted Roth