[Top][All Lists]

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

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

From: Dave Hansen
Subject: Re: [avr-gcc-list] How to (efficeiently !!!) test abitwithinamulti-byte intege
Date: Fri, 04 Nov 2005 17:26:40 -0500

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.


reply via email to

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