[Top][All Lists]

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

[avr-libc-dev] [Commit] Re: document <avr/delay.h>

From: Joerg Wunsch
Subject: [avr-libc-dev] [Commit] Re: document <avr/delay.h>
Date: Wed, 22 Dec 2004 00:07:14 +0100
User-agent: Mutt/

As Marek Michalkiewicz wrote:

> > If so, please suggest a suitable implementation...  I'm willing to
> > commit it (and to do some limited testing).

> Something like:

> #define udelay(us) _delay_loop_1(((F_CPU)/3.0e6) * (us) + 1)
> #define mdelay(ms) _delay_loop_2(((F_CPU)/4.0e3) * (ms) + 1)

> The delay is rounded up a little, to guarantee minimum loop count of
> 1 (because 0 is actually 256 or 64K loops!) for any non-negative
> delay.

Rounding it up sounds illogical to me, as the compiler's overhead to
setup the loop counter already costs time, so this solution tends to
always take more time than intented.

Anyway, thanks, I've seen the light now, and turned these macros into
inline functions.  Using temporary ``variables'' (which will be
optimized away anyway), it's a lot cleaner to express the logic behind
it, and to perform a simple bounds checking.  Thus arguments that
would come out as 0 can silently be made 1, and arguments overflowing
the domain can be made 0 (which is the maximum delay for each of the

I just committed the attached patch.  I did some basic checking on it
before.  On a 14.7456 MHz clocked ATmega128, I get:

Doing minimal delay: done.  Time: 2.170139e-06 s
Doing 1000 loops of 10 ms each: done.  Time: 10.053112 s
Doing 50000 loops of 50 µs each: done.  Time: 2.529284 s
Doing maximal delay: done.  Time: 0.017873 s

The minimal delay is a _delay_us(0.1), the maximal delay is a
_delay_ms(5555), the remainder is self-explanatory.  Seems to be OK to
me.  (I verified the assembler output for the corner cases, the arg is
really set to 1, or 0 respectively.)

> > Please do soon, as I really intend to roll a 1.2.0 release ASAP.

> I think it is important to move attiny2313 and attiny13 from avr4 to
> avr2 first (at the same time in avr-libc, binutils and gcc), to fix
> the recently reported bug (use of unsupported MUL instructions).

OK, will do tomorrow.  Did I get it right that the only change
required is a modification of configure.in?

cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Attachment: avr-delay.diff
Description: Text document

reply via email to

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