Strange delay behavior in Atmega328P

Question

So, I have implemented a custom delay function using the standard one found at utils/delay.h.

inline void delay_us(uint16_t time) {
    while (time > 0) {
        _delay_us(1);
        time--;
    }
}

It's called inside a loop in the main function:

#define F_CPU 16000000UL

...

int main() {
    pin_mode(P2, OUTPUT);
    while (1) {
        pin_enable(P2);
        delay_us(1);
        pin_disable(P2);
        delay_us(1);
    }
}

Using an oscilloscope, I can tell that the pin stays 1.120us high and 1.120us low, with 1 as parameter. Incrementing the parameter to 6, the the oscilloscope shows me 6.120us. But with 7, it stays 9 us. With 10, about 14 us.

I know the loop comes with an overhead, but why there is no overhead (or why the overhead does not changes) between 1 and 6 us?

OBS: I'm using an Arduino UNO (16 MHz)

Probably it is unrolling the loop for small values of `time`. Try using a variable as a parameter rather than a constant. — Eugene Sh., Oct 17 '18 at 21:43
1 us is 16 CPU clock cycles. So, actually, all the delay you have is overhead rather than "_dethe lay...". Since you made function "inline", the compiler just replaces its call (assuming the parameter is a constant) with an inlined loop. So it is mostly depended on how compiler will optimize that loop (e.g. unroll it, etc) — AterLux, Oct 17 '18 at 22:57
@EugeneSh. the delay function just allow an integer constant as parameter. — Hugo Sartori, Oct 18 '18 at 02:00
Is there a proper way to implement a delay with micro precision without doing assembly code? — Hugo Sartori, Oct 18 '18 at 02:04
Best way for a delay function is to use timer. Always remember the optimiziation of your compiler. — Mike, Oct 18 '18 at 06:04
I agree that doing this with a timer is the way to go. But if that is not possible and the quality of the output signal relies strongly on how many cycles are used for an operation, I would suggest to do it in assembly instead of compiled code. — Stefan Bormann, Oct 18 '18 at 11:52
@HugoSartori `delay_us(x)` where `x is a variable you, say, read from user or calculate in runtime. In this scenario the compiler won't know how long the loop is and will not unroll it. — Eugene Sh., Oct 18 '18 at 13:43
I guess I'll need to spend some time analysing the generated assembly for different scenarios. — Hugo Sartori, Oct 18 '18 at 14:17
@StefanBormann I thought about that, but I'm developing a small library to use PWM, so I'm trying to not cause unexpected behavior. — Hugo Sartori, Oct 18 '18 at 14:20
Yea, that jitter is unexpected. You can totally avoid that by using the timer hardware of the controller - that's easy for PWM. — Stefan Bormann, Oct 18 '18 at 14:35
If clock frequency doesn't change you could also fine tune using `_NOP()` from `avr/cpufunc.h`. Not very flexible, though. — vega8, Dec 07 '18 at 20:02

score 2 · Accepted Answer · answered Dec 07 '18 at 20:00

For small arguments gcc-avr will unroll the while loop, effectively stringing together multiple 1µs-delays:

delay_us(5):
    ldi r24,lo8(5)
    mov r25,r24
    1: dec r25
    brne 1b
    mov r25,r24
    1: dec r25
    brne 1b
    mov r25,r24
    1: dec r25
    brne 1b
    mov r25,r24
    1: dec r25
    brne 1b
    1: dec r24
    brne 1b

At some point however, the compiler changes its strategy from space-consuming unrolling to actually branching through the while loop:

delay_us(6):
    ldi r24,lo8(6)
    ldi r25,hi8(6)
    ldi r19,lo8(5)
.L2:
    mov r18,r19
    1: dec r18
    brne 1b
    sbiw r24,1
    brne .L2

At that time, the carefully crafted _delay_us() function will be more or less defeated. The branch overhead is significant compared to the 16 clock cycles needed for a single _delay_us(1) and will be paid for every loop iteration.

The sudden increase in runtime you describe is basically the point at which your compiler stops to unroll the loop.

Compare this to calling _delay_us(6) directly:

_delay_us(6):
    ldi r24,lo8(32)
    1: dec r24
    brne 1b

The assembly shown above might differ somewhat from what your compiler is doing since compiler output can vary significantly with version and flags but the listings should be reasonably close. For the examples I assumed gcc-avr 4.6.4 with optimization level -O2. Try it out

Strange delay behavior in Atmega328P

1 Answers1