Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>

[Marek Michalkiewicz]

Hello,

On Mon, Dec 20, 2004 at 09:36:39AM +0100, Joerg Wunsch wrote:

> Do people really think it's worth the while moving the macros to FP?

One nice thing is a compiler warning if the delay is out of range
(overflow in implicit constant conversion).

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

> 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).
The fix is sub-optimal (MOVW not used, even though it is available),
but we probably can't do any better so close to the GCC 4.0 release...

Without going to per-device multilibs, it shouldn't be too difficult
to make GCC generate MOVW in user's code only (not in avr2 libc as
that has to work on all avr2 devices, including those without MOVW).
This would not be perfect, but still useful (applications on such small
devices can't use much of libc code anyway).  But this is not strictly
a bug fix (just optimization), so probably is best done after 4.0.

Regards,
Marek