Re: NRF52 and timing - actual state and what functions to use? #nrf52-pca10040
Andy Ross
On 1/5/20 4:30 AM, Martin Kozusky [newsgroups] wrote:
1 - what is the best solution to call my function every 1ms (or willPeriodic k_timer's do not work in fractional ticks, no. If you schedule a 1000ms timeout it will be rounded up internally to exactly 33 hardware cycles, and that process will repeat each cycle. So you would see the ~993 Hz tick rate you calculated. If you want to work in fractional ticks, the application needs to do that math itself. 2 - what is the best solution for most precise long-term timeLong term time is kept as a 64 bit count of ticks, so it's not subject to the kind of round-off errors that periodic timers are. As long as your app isn't dropping or delaying the counter interrupts, the uptime value should be as accurate as your crystal is. If you want to get 1 callback per second as a long term average, you can (with care) compute your timeout as an offset from system start or some other time reference instead of "now" (i.e. the Nth timeout will happen at "N * 1000ms", plus a little precision slop due to the clock mismatch). There's actually an API change which will make this kind of code significantly easier, see https://github.com/zephyrproject-rtos/zephyr/issues/21305 As far as using a different oscillator to drive the timer, that's possible but requires some driver fiddling. I'll let the Nordic folks speak to that. One option might be to use the generic ARM SysTick driver, which doesn't have the rate mismatch issues of the 32kHz timer, but doesn't have the low power idle characteristics. Andy
|
|