In the latest commit to the v1 branch of libuavcan we have ported the old time.hpp abstraction over but have yet to provide more definition for system time. We do have monotonic timestamps on received frames that are documented to be a “hardware supplied monotonic time value” but no other definition has been defined.
The questions for this thread are:
- Do we want to continue to provide system clock and time value abstractions or do we remove time.hpp and go all-in with the C++ chrono abstractions?
- Should we require that rx timestamps be related to system time in some manner?
The argument for using this abstraction are that it’s a proven one (it’s about 8 years old now?) designed by professionals to be portable and efficient. The only reason I can think of for not using it is the unknown difficulty in supporting it on embedded systems. I personally have never used chrono time on a micro-controller so, before I have an opinion, I need to look at the support for it in nanolib and newlib. What other outliers are people aware of that could cause people to avoid libuavcan because of chrono support? Does anyone have experience implementing chrono clock abstractions?
My current inclination is to avoid any requirements other than the timestamps on received frames are monotonic and that they don’t roll over (i.e. 64-bit == geologic timescales == rollover cannot happen because the hardware itself will have disintegrated into its constituent components before this would happen). Is there any other reason to put further constraints on these timestamps? Remember that requiring correlation between system time and hardware timestamps could severely limit the ability to support some platforms like linux where the application using libuavcan has very little control over this.