The Nordic board are selecting CONFIG_ARCH_HAS_CUSTOM_BUSY_WAIT by
default and rely on some HAL code to implement a cycle accurate busy
delay loop.
This is in general fine for real hardware but when QEMU and emulation is
taken into account, a cycle accurate busy wait implementation based on
delay in executing machine code can be misleading.
Let's take for example qemu_cortex_m0 (that is based on the nRF51
chipset) and this code:
uint32_t before, after;
while (1) {
before = k_cycle_get_32();
k_busy_wait(1000 * 1000);
after = k_cycle_get_32();
printk("diff cycles: %d\n", after - before);
}
With CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=1000000 this diff cycles should
be always around 1000000, in reality when executed with:
qemu-system-arm -cpu cortex-m0 -machine microbit -nographic
-kernel build/zephyr/zephyr.elf
This results in something like this:
diff cycles: 22285
diff cycles: 24339
diff cycles: 21483
diff cycles: 21063
diff cycles: 21116
diff cycles: 19633
This is possibly due to the fact that the cycle accurate delay busy loop
is too fast in emulation.
When dealing with QEMU let's use the reliable busy loop implementation
based on k_cycle_get_32() instead.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
7a48ad34d9