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: Jan-Hinnerk Reichert
Subject: Re: [avrdude-dev] Bad programming speed on AT90S8535 using AVRdude
Date: Tue, 18 Nov 2003 20:24:20 +0100
User-agent: KMail/1.5.1

On Tuesday 18 November 2003 19:26, Theodore A. Roth wrote:
> 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:

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

Agreed.

> > 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:
[...]
> 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.

I'm a unix (linux 2.4.23-pre8) guy, too ;-)
I understand the problem (I feel it every time I use cdrdao). However, 
I think programming should be fast.

Perhaps it is best to make some speed tests first. If busy-waiting 
does not give a significant gain there is no need for further 
discussion.

BTW: Perhaps we could use sched_yield() to make it behave better.

[some URL]
> He's saying that gettimeofday() is a bit too course grained.

This shouldn't be a problem here: gettimeofday() is only used to 
determine if the write has failed.

Pseudo-Code:
if (polling_is_OK)
  do {
     poll
  } while (!ready) && (!timed_out)

Since there is no timeout in normal operation, the timeout can be much 
larger than max_write_delay.

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

Under FreeBSD usleep() is using select(), under Linux it is using 
nanosleep().

I think there is still the same granularity issue with select() under 
Linux ;-(

/Jan-Hinnerk





reply via email to

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