I am experimenting with suspend to RAM power saving feature on my debian platform while using uavcan::Timer. As I understand, uavcan::Timer uses software timer (clock_gettime with CLOCK_ MONOTONIC) and therefore does not “tick” while suspended.
My platform automatically sync systemtime with RTC when waking up from low power mode, but it looks like it does not affect the timers, hence they resume ticking from the point in time low power mode was entered. As a result, the expected duration of the timers are not correct.
Are there any side affect if changing to CLOCK_REALTIME?
I may expect that changing RTC/System time may have an impact…
The side effects would be huge. If your objective is to measure time intervals, you use a steady (aka monotonic) clock. If your objective is to measure an exact time when a certain event took place and compare this measurement against similar samples taken by other participants of a given process, you need a synchronized clock (system time).
A monotonic clock guarantees that the time delta between temporally separate events is observable. A system clock guarantees that the time of an individual event is observable, but a time delta may not be possible to measure due to the clock changing its rate and/or phase to stay synchronized with an external reference. There is no known method of combining both of the desirable properties in one time source.
Until now I have used the lib timers to periodically generate broadcasts etc. But now I am implementing power save mode (suspend to ram) so that approach will not work anymore.
I will basically implement an asynchroneous behavior with the power down period, without having timers running in the background.
Ofcource, I cannot do anything about the built in timers in the stack. But that would not affect my application as I know.
I think I will do a similar Timer class but that uses UTC system time instead, hence the exact relative time measurment is not needed in my application.