Re: [avr-gcc-list] How to (efficeiently !!!) test abitwithinamulti-byte intege

[Dave Hansen]

From: "David Brown" <address@hidden>
[...]
> The bug is almost certainly a delay loop variable that is not declared
> volatile.  The delay function is probably something like:
>
> void shortDelay(void) {
>     uint8_t n = 50;
>     while (n--);
> }
>
> That (might) work fine with little or no optomisation, but when 
> optomisation
> is on, it fails.  The solution is simply to make n "volatile".  Note that 
> it
> will not give you precise control of your delay - different optomisations 
> or
> different compiler versions might give slightly different code, and may or
> may not inline the function.  But in a case like this it doesn't matter -
> all you are looking for is a slight delay, and it doesn't matter if it is
> too long.  I've done exactly this sort of thing (with "volatile", 
> naturally)
> myself for LCD routines.

FWIW, I always had good luck with the delay functions in delay.h for short 
hardcoded (usec) delays.  I don't have access to the code now, but I had a 
macro that calculated the minimum number of trips through the four-cycle 
loop that would guarantee the specified delay.  Something like

  #define usec_count_(x) ((OSC_FREQ*(x))/4000000)
  #define delay_us(x) _delay_loop_2(usec_count_(x))

It looks like the library also provides _delay_us, which might be better, 
though I've never tried it.  Requires you to #define F_CPU before #including 
avr/delay.h.

Regards,
  -=Dave