> You wouldn't really do this from application level, right?
No, I don't want to do this from application level hence why I am looking for an alternative. NuttX also has function clock_resynchronize() that should solve the problem with time going backwards but not sure if it has ever been tested and used. Thank you for the link and issue about adjtime(), that seems like a good alternative and way to go. Best regards, Michal Lenc ---------- Původní e-mail ---------- Od: Gregory Nutt <spudan...@gmail.com> Komu: dev@nuttx.apache.org Datum: 21. 3. 2023 0:20:43 Předmět: Re: RTC synchronization with system time "You wouldn't really do this from application level, right? There is currently no POSIX-compatible application interface to do that. But you could implement a kernel thread that is started in your board initialization logic that can call clock_synchronize() according to whatever criteria you need. I suppose a standard kernel thread could also be implemented in sched/clock if such a one-size-fits-all solution can be imagined. You might check out logic in sched/clock for CONFIG_CLOCK_TIMEKEEPING. That is used primarily for adjusting the time to properly track time from NTP. Seems to me that that is essentially the same issue: Keeping two clocks in agreement. On 3/20/2023 4:20 PM, Michal Lenc wrote: > Hello all, > > > > 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. However I was not able to find any > implementation that would automatically synchronize system time with > (correct) values from RTC if system clock drifts from real time. It seems > the only possible option is to "force" the synchronization by calling the > mentioned clock_synchronize() function periodically from application level. > > > > > What is your view on adding some sort of automatic synchronization that > would ensure system clock stays in sync with RTC (or at least error is less > than some value) even when i drifts away from "real time"? Quite simple > solution is to let clock_gettime() to update base time after N reads however > this would add some computation complexity to gettime (I2C communication > delay for external RTC etc.) and I am not sure if we really want this inside > clock_gettime(). > > > > > Best regards, > Michal Lenc > "
