avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Theodore A. Roth
Subject: Re: [avrdude-dev] Bad programming speed on AT90S8535 using AVRdude
Date: Tue, 18 Nov 2003 10:26:01 -0800 (PST)


On Tue, 18 Nov 2003, Jan-Hinnerk Reichert wrote:

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

Agreed.

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

I'd go with max_write_time only. If the part isn't programmed after that
much time, there's not much we can do regardless of the value of Vcc and
should probably just fatal error out.

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

Like I said, that's just psuedo code. ;-)

gettimeofday() should be portable for that most part. There is this:

  
http://sprg.ssl.berkeley.edu/~fastops/ITOS/portable/clock$_gettime$28$29_vs_gettimeofday$28$29.html

but we could handle that if the need arises.

The reason us unix guys would prefer the usleep() approach over a busy
loop is to free up the cpu for other processes. There's got to be a sane
way to do sub-second delays on windows without resorting to a busy loop.

A little more searching with google, turned up this:

  www.cs.pdx.edu/~robboy/CLASSES/CS201/slides/time.measurement.pdf

He's saying that gettimeofday() is a bit too course grained.

The more I read about this, the more I think that select() is the best
way to get sub-second timing delays. There is this wart on linux though:

       On Linux, the function select modifies timeout to reflect the
       amount of time not slept; most other implementations do not do
       this.  This causes problems both when Linux code which reads
       timeout is ported to other operating systems, and when code is
       ported to Linux that reuses a struct timeval for multiple selects
       in a loop withoutreinitializing it.  Consider timeout to be
       undefined after select returns.

According to this:

  http://cygwin.com/cygwin-api/std-misc.html

select() under cygwin should be compatible and do what we want.

Not sure if this is relevant, but I also found this:

  http://mkssoftware.com/docs/man3/select.3.asp

Ted Roth




reply via email to

[Prev in Thread] Current Thread [Next in Thread]