[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/1.4.2.1i |
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
loops).
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. ;-)
avr-delay.diff
Description: Text document
- [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Joerg Wunsch, 2004/12/19
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, René Liebscher, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Joerg Wunsch, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Marek Michalkiewicz, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, E. Weddington, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Marek Michalkiewicz, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Joerg Wunsch, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, E. Weddington, 2004/12/20
- Re: [avr-libc-dev] [CVS commit: HEAD] document <avr/delay.h>, Marek Michalkiewicz, 2004/12/20
- [avr-libc-dev] [Commit] Re: document <avr/delay.h>,
Joerg Wunsch <=