c76dd1edb7
The default system clock on all Nordic devices is based on a 32 KiHz (2^15 Hz) timer. Scheduling ticks requires that deadlines be specified with a timer counter that aligns to a system clock. With the Zephyr default 100 clocks-per-sec configuration this results in 100 ticks every 32700 ticks of the cycle timer. This reveals two problems: * The uptime clock misrepresents elapsed time because it runs 0.208% (68/32768) faster than the best available clock; * Calculation of timer counter compare values often requires an integer division and multiply operation to produce a value that's a multiple of clock-ticks-per-second. Integer division on the Cortex-M1 nRF51 is done in software with a (value-dependent) algorithm with a non-constant runtime that can be significant. This can produce missed Bluetooth deadlines as discussed in upstream #14577 and others. By changing the default divisor to one that evenly divides the 2^15 clock rate the time interrupts are disabled to manage timers is significantly reduced, as is the error between uptime and real time. Do this at the top level, moving SYS_CLOCK_HW_CYCLES_PER_SEC there as well since the two parameters are related. Note that the central_hr configuration described in upstream #13610 does not distinguish latency due to timer management from other irq_block/spinlock regions, and the maximum observed latency will still exceed the nominal 10 us allowed maximum. However this does occur much less frequently than changing the timer deadline which can happen multiple times per tick. Signed-off-by: Peter A. Bigot <pab@pabigot.com> |
||
|---|---|---|
| .. | ||
| arc | ||
| arm | ||
| nios2 | ||
| posix | ||
| riscv32 | ||
| x86 | ||
| x86_64/x86_64 | ||
| xtensa | ||
| Kconfig | ||