tinygo-org
rp2040: rtc support
Real Time Clock on RP2040.
Probably, not very useful by itself, but the ability to fire a scheduled interrupt enables us to support RTC-governed Deep Sleep and Dormant states later.
Example output
SYS: 2006-01-02T15:04:08Z, RTC: 2006-01-02T15:04:09Z, DIFF: 999.148ms
SYS: 2006-01-02T15:04:09Z, RTC: 2006-01-02T15:04:10Z, DIFF: 997.986ms
SYS: 2006-01-02T15:04:10Z, RTC: 2006-01-02T15:04:11Z, DIFF: 997.155ms
SYS: 2006-01-02T15:04:11Z, RTC: 2006-01-02T15:04:12Z, DIFF: 996.361ms
SYS: 2006-01-02T15:04:12Z, RTC: 2006-01-02T15:04:13Z, DIFF: 995.58ms
SYS: 2006-01-02T15:04:13Z, RTC: 2006-01-02T15:04:14Z, DIFF: 994.825ms
SYS: 2006-01-02T15:04:14Z, RTC: 2006-01-02T15:04:15Z, DIFF: 994.061ms
SYS: 2006-01-02T15:04:15Z, RTC: 2006-01-02T15:04:16Z, DIFF: 993.29ms
SYS: 2006-01-02T15:04:16Z, RTC: 2006-01-02T15:04:17Z, DIFF: 992.508ms
SYS: 2006-01-02T15:04:17Z, RTC: 2006-01-02T15:04:18Z, DIFF: 991.733ms
SYS: 2006-01-02T15:04:18Z, RTC: 2006-01-02T15:04:19Z, DIFF: 990.949ms
Pekabo!
SYS: 2006-01-02T15:04:19Z, RTC: 2006-01-02T15:04:20Z, DIFF: 990.173ms
SYS: 2006-01-02T15:04:20Z, RTC: 2006-01-02T15:04:21Z, DIFF: 989.389ms
SYS: 2006-01-02T15:04:21Z, RTC: 2006-01-02T15:04:22Z, DIFF: 988.624ms
SYS: 2006-01-02T15:04:22Z, RTC: 2006-01-02T15:04:23Z, DIFF: 987.844ms
~Interesting to see the diff decrease. (approx 800us per second.)~ ~This means RTC ticks faster than the system clock.~ ~Which of them is correct is hard to tell though.~
This is all due to the fact RTC returns seconds precision and the loop iteration takes slightly more than a second (1 second and ~800µs to be precise).
Both clocks have exactly same value internally, they run from the same source (XOSC).
The accumulated error is immediately visible in the value of the system clock (µs precision) and is not visible until it adds up to more than a second in RTC case.
The moment error accumulates to a whole second, the output jumps two seconds for both SYS and RTC.
Confirmed by letting the (slightly modified) example run for 20 minutes:
...
SYS: 2006-01-02T15:23:33Z, RTC: 2006-01-02T15:23:33Z, DIFF: -998.923ms, DIFF':846µs
SYS: 2006-01-02T15:23:34Z, RTC: 2006-01-02T15:23:34Z, DIFF: -999.788ms, DIFF':865µs
SYS: 2006-01-02T15:23:36Z, RTC: 2006-01-02T15:23:35Z, DIFF: -1.000628s, DIFF':840µs
SYS: 2006-01-02T15:23:37Z, RTC: 2006-01-02T15:23:37Z, DIFF: -1.507ms, DIFF':-999.121ms
SYS: 2006-01-02T15:23:38Z, RTC: 2006-01-02T15:23:38Z, DIFF: -2.366ms, DIFF':859µs
SYS: 2006-01-02T15:23:39Z, RTC: 2006-01-02T15:23:39Z, DIFF: -3.187ms, DIFF':821µs
...
I shall probably modify the example and remove the confusing DIFF output.
If possible I would not expose a RtcTime type. That should be a time.Time. I've suggested having a machine.Time type that basically implements the whole functionality of time.Time, to then be imported by time package.
If we do not create a machine.Time type I believe we should probably give the RTC type similar methods to time.Time, such as Date (copy Date signature) and Clock (copies Clock signature) and Nanosecond (copies Nanosecond signature).
Same for SetAlarm, which could be SetAlarmDate and take same parameters as time.Date if we choose to drop the RtcTime type.
Last Point: If you we do choose to keep RtcTime I'd encourage it be renamed to be RTCTime, in line with Go convention of acronyms according to Code Review Comments.
