nordic: Rely on internal busy_wait implementation for QEMU
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>
This commit is contained in:
parent
93fa8f84d3
commit
7a48ad34d9
1 changed files with 1 additions and 1 deletions
|
@ -26,7 +26,7 @@ config SYS_CLOCK_TICKS_PER_SEC
|
|||
default 32768
|
||||
|
||||
config ARCH_HAS_CUSTOM_BUSY_WAIT
|
||||
default y
|
||||
default y if !QEMU_TARGET
|
||||
|
||||
config PM
|
||||
default y if SYS_CLOCK_EXISTS && !HAS_NO_PM && MULTITHREADING
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue