Actually, the situation is much worse:
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/sama5/sama5d3x-ek/README.txt#L2823
If you use 32.768KHz clock source, then there is a small error in every
time conversion since 1/32768 cannot be represented in microseconds.
Normally, this will result in small errors as you have noted. However,
in a very busy system with man timers, that error builds up and can be
quite large... like 50% error! See the above reference.
That huge error is not acceptable in most cases.
On 7/11/2021 9:16 AM, Gregory Nutt wrote:
The other source of the inaccuracy can be in clock frequency. I use
32 kHz
clock source, but this value cannot be properly represented by
CONFIG_USEC_
PER_TICK, which I set to 31 (which is aproximately 32.25 kHz). But 32
kHz
clock source seems to be the only possible in iMXRT as others are to
hight
(tens or hundreds of MHz) and can´t be represended by the timer
prescaler
divider. Did anyone have similar problems when implementing tickless
mode
for some platforms?
I ran into this same issue with some Atmel SAM parts (I forget which)
and I think that there is some discussion in the README files somewhere.
I never really found a great solution. Options that I though of:
- Change CONFIG_USEC_PER_TICK to CONFIG_TICK_FREQUENCY. A frequency
can be represented with an integer more accurately that can a time
period. 32768Hz is exact where as 1/32768 sec = 0.000030517578125...
sec cannot be represented exactly in microseconds.
- Use some kind of internal, higher precision, accurate version of
event time that is converted to and from the hardware clock time.
I didn't like either of these because the first would affect a lot of
code and the second could be computationally expensive.