avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] A _delay_us_2() with 16 bit max & nop shimming


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] A _delay_us_2() with 16 bit max & nop shimming
Date: Sun, 27 Aug 2006 22:22:52 +0200
User-agent: Mutt/1.5.11

Thanks for your contribution!

At the very first, please submit that as a bug report (mark it as a
feature request) so it won't be forgotten:

https://savannah.nongnu.org/bugs/?group=avr-libc

I'd also appreciate if you somehow indicated your full name so we
could use it for attribution purposes (Copyright statement update, CVS
log).

As address@hidden wrote:

> The major malfunction here - this DOES NOT compile without
> optimization.  Would it be acceptable to #define it away in that
> case?

I think so, yes.  I just verified, the preprocessor gets the symbol
__OPTIMIZE__ passed (as value 1) if any optimization level > 0 is
requested.  So the header file could issue different code for both
situations.

Usually, when you start with that kind of #ifdef spaghetti, it's best
to add a separate branch for #ifdef __DOXYGEN__ then which will be
used for documentation purposes.

> The lesser bug is that _delay_us_2() only works with a constant; who
> wants float arithmetic at runtime, anyway?

This is OK, and I'd even agree that the code might throw some kind of
compile-time error if not being passed a compile-time constant.

> This delay.h adds _delay_us_2() which is more precise and has a
> larger max than _delay_us().  There is also a _delay_loop_2b()
> added.

It's not necessary to add a new function for that.  We *are* the
authorities of the library, and if a better implementation than the
current one can be found, it doesn't make sense to have both, the
inferior and the new one around.  (Of course, if the above
optimization stuff requires the old version to be around for the
non-optimized case, that's another matter.)

> The else {/*NOTREACHED*/} could be filled in with a still larger
> delay routine for almost unlimited us count.

I think there's already a suggestions in the bugs database for that.
You might verify that yourself if you want.

> +static inline void _delay_loop_2b(uint16_t __count) 
> __attribute__((always_inline));

> +#define _delay_loop_2b( __count)\

These lines are self-contradictory.

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

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





reply via email to

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