RTC issues on PYBD (STM32)
We've encountered a number of issues using the RTC on PYBD across a number of devices. These include
- RTC stopping entirely (subsequent calls to the RTC return exactly the same value)
- RTC blocking for ~1 sec when getting or setting the time
- RTC returning a plausible but incorrect value (I think a bit has become 'stuck')
These faults are often intermittent making debugging quite difficult.
As such, for our application code we are now using a 'soft' RTC based off CPU ticks, and synchronising from the network on a regular basis.
time is messed-up (RTC and utime)
Background: I'm trying to enable lwip's sntp client on the esp32 and it's not going so well... The reason is the EPOCH. The world thinks it's 1970, MP thinks it's 2000. Oops.
I looked at the machine.RTC mess, utime, #5733 and #5553. On an unconnected MP board, such as a pyboard perhaps with a GPS module the existing RTC and utime make a lot of sense. It's very little code, the RTC can be set via pyboard over USB or by app code using the GPS. Thereafter the app can get the time.
On a connected board, such as esp or pybd, the existing RTC and utime make much less sense. The lwip sntp client does what you'd expect it to do and steps or slews the RTC (your choice). There's a good set of std C functions to manipulate time (gettimeofday, mktime, localtime, etc). The machine.RTC module can of course be useful if Wifi is off, etc, but it's kind'a duplicated code. The utime localtime and mktime are a hazard given the they use a different epoch than lwip. On the pybd all this is not a huge issue 'cause there's no SNTP...
I'm not sure how to fix this without spending a lot of work with an uncertain outcome... It seems easier to just write a dynamically loadable native module for the esp32 that uses the lwip sntp and std C time functions and forget about RTC and utime. Thoughts?