NuttX offers a function clock_synchronize() that synchronizes system clock with
clock from RTC (internal or external). The synchronization is done
during board initialization and I suppose this can also be called from an
application level if required.
I think clock_synchronize() is okay for startup initialization, but
would be inappropriate at run time. That is because it could cause the
current time to apparently jump backward. That could be fatal under
certain circumstances as described for adjtime() in
https://github.com/apache/nuttx/issues/8858
I remember once reading about how FreeBSD handles this (I think it was
FreeBSD; this was a long time ago):
If there is a difference between the system clock and the reference clock,
the system clock is _not_ assigned the reference clock's time, exactly
because of the "clock running backwards" problem. Rather, when the clock is
advanced, the advancement is adjusted by a small amount, so that the system
clock always runs forwards, never backwards, and over time the system clock
gradually comes into synchronization with the reference clock.
We probably need something like that to avoid the same problem.
We have adjtime() in sched/clock/clock_timekeeping, but it has quite a
few problems. See https://github.com/apache/nuttx/issues/8858
This is the same API used by both Linux and FreeBSD:
* Linux: https://man7.org/linux/man-pages/man3/adjtime.3.html
* FreeBSD: https://man.freebsd.org/cgi/man.cgi?query=adjtime&sektion=2&n=1
adjtime(), as specified, fixes the problem of time going backward to
modify the rate of the clock, not the time value of the clock. Both
Linux and FreeBSD specify that adjtime() controls the rate of the clock
source. since only the rate is adjusted, the time will not go backward,
only slow down until it is correct.
Greg
