Ttdfjt

I'm working on a project involving a cortex-m4 mcu (LPC4370).
And I need to insert a delay while turning on compiler's optimization.
So far my workaround was to move up and down a digital output inside a for-loop:

for (int i = 0; i < 50000; i++)

 LPC_GPIO_PORT->B[DEBUGPIN_PORT][DEBUG_PIN1] = TRUE;
 LPC_GPIO_PORT->B[DEBUGPIN_PORT][DEBUG_PIN1] = FALSE;

But I wonder if there's a better way to fool GCC.

The context of this inline no-dependency delay is missing here. But I'm assuming you need a short delay during initialization or other part of the code where it is allowed to be blocking.

Your question shouldn't be how to fool GCC. You should tell GCC what you want.

#pragma GCC push_options
#pragma GCC optimize ("O0") 

for(uint i=0; i<T; i++)__NOP()

#pragma GCC pop_options

From the top of my head, this loop will be approximately 5*T clocks.

(source)

Fair comment by Colin on another answer. A NOP is not guaranteed to take cycles on an M4. If you want to slow things down, perhaps ISB (flush pipeline) is a better option. See the Generic User Guide.

Use a timer if you have one available. The SysTick is very simple to configure, with documentation in the Cortex M4 User guide (or M0 if you're on the M0 part). Increment a number in its interrupt, and in your delay function you can block until the number has incremented a certain number of steps.

Your part contains many timers if the systick is already in use, and the principle remains the same. If using a different timer you could configure it as a counter, and just look at its count register to avoid having an interrupt.

If you really want to do it in software, then you can put asm("nop"); inside your loop. nop doesn't have to take time, the processor can remove them from its pipeline without executing it, but the compiler should still generate the loop.

Not to detract from other answers here, but exactly what length delay do you need? Some datasheets mention nanoseconds; others microseconds; and still others milliseconds.

• Nanosecond delays are usually best served by adding "time-wasting" instructions. Indeed, sometimes the very speed of the microcontroller means that the delay has been satisfied between the "set the pin high, then set the pin low" instructions that you show. Otherwise, one or more NOP, JMP-to-next-instruction, or other time-wasting instructions are sufficient.


• Short microsecond delays could be done by a for loop (depending on CPU rate), but longer ones may warrant waiting on an actual timer;


• Millisecond delays are usually best served by doing something else completely while waiting for the process to complete, then going back to ensure that it has actually been completed before continuing.

In short, it all depends on the peripheral.

The best way is to use on-chip timers. Systick, RTC or peripheral timers. These have the advantage that the timing is precise, deterministic and can be easily adapted if CPU clock speed is changed. Optionally, you can even let the CPU sleep and use a wake-up interrupt.

Dirty "busy-delay" loops on the other hand, are rarely accurate and come with various problems such as "tight coupling" to a specific CPU instruction set and clock.

Some things of note:

• Toggling a GPIO pin repeatedly is a bad idea since this will draw current needlessly, and potentially also cause EMC issues if the pin is connected to traces.


• Using NOP instructions might not work. Many architectures (like Cortex M, iirc) are free to skip NOP on the CPU level and actually not execute them.

If you want insist on generating a dirty busy-loop, then it is sufficient to just volatile qualify the loop iterator. For example:

void dirty_delay (void)

 for(volatile uint32_t i=0; i<50000u; i++)
 ;

This is guaranteed to generate various crap code. For example ARM gcc -O3 -ffreestanding gives:

dirty_delay:
 mov r3, #0
 sub sp, sp, #8
 str r3, [sp, #4]
 ldr r3, [sp, #4]
 ldr r2, .L7
 cmp r3, r2
 bhi .L1
.L3:
 ldr r3, [sp, #4]
 add r3, r3, #1
 str r3, [sp, #4]
 ldr r3, [sp, #4]
 cmp r3, r2
 bls .L3
.L1:
 add sp, sp, #8
 bx lr
.L7:
 .word 49999

From there on you can in theory calculate how many ticks each instruction takes and change the magic number 50000 accordingly. Pipelining, branch prediction etc will mean that the code might execute faster than just the sum of the clock cycles though. Since the compiler decided to involve the stack, data caching could also play a part.

My whole point here is that accurately calculating how much time this code will actually take is difficult. Trial & error benchmarking with a scope is probably a more sensible idea than attempting theoretical calculations.