To avoid the accumulation of conversion error, the count in timer driver should use the same time unit as the hardware. BTW, your timer driver has to implement the up_alarm_xxx functions.
On Sun, Jul 11, 2021 at 9:10 AM Gregory Nutt <spudan...@gmail.com> wrote: > 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. > > > > > >
