Re: [avr-chat] ensuring that _delay_us() gets a compile-time double constant

[Rogier Wolff]

On Tue, Dec 02, 2014 at 04:35:10PM -0900, Britton Kerin wrote:
> On Tue, Dec 2, 2014 at 3:36 PM, Michael Hennebry
> <address@hidden> wrote:
> > On Tue, 2 Dec 2014, Britton Kerin wrote:
> >
> >> 1.  Does _delay_us() need a double const, or is an int const guaranteed
> >>    to work?    The avr libc manual just says "known const" in one place,
> >>    but the signature     calls for a double.
> >
> >
> > _delay_us needs a double const.
> > It will get a double whether you give it a double or some other number.
> > That is what prototypes are for.
> > Prototypes are ordinary C.
> 
> Yes, but in many cases the type coercian for that happens at run-time.

No. When it is a constant, this happens at compile time. This 
is what _delay_us depens on: It does a bunch of calculations, 
comes to "this requires XXX clocks delay" and then arranges for
that many clock cycles delay. There ends up being no function
call in your binary for _delay_us!

> >>    In file included from one_wire_slave.c:8:0:
> >>    /home/bkerin/opt/avr/avr/include/util/delay.h: In function
> >> ‘ows_write_bit’:
> >>    /home/bkerin/opt/avr/avr/include/util/delay.h:163:28: error:
> >> __builtin_avr_delay_cycles expects a compile time integer constant
> >>      __builtin_avr_delay_cycles(__ticks_dc);
> >
> >
> > My guess is that a variable or a non-constant
> > expression was passed to _delay_us.
> 
> Yes, sorry I wasn't clear:  This was what happens when I pass a known
> non-const.  I'm just wondering if this trap is dependable, and if it catches
> non-double consts, if that's an issue.

It catches the "non-constant" case. If you call _delay_us (1); the
compiler will make that into _delay_us (1.0); as the first step.

After some macro magic it will end up  __builtin_avr_delay_cycles(20);
(if your clock speed is 20MHz). Note that the argument is an integer
again!. 

        Roger. 

-- 
** address@hidden ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.