The STM32 have the RTC component but it isn’t implemented in the default firmware. So is what I was saying: without modification, not usable.
But possible 
Sorry, I find it surprising (and maybe kind of funny) that so far no one has bothered to build a firmware that takes advantage of it.
Haven’t checked the particular STM32 chip used on the PicoCalc, but not all STM32 can clock the RTC off the main crystal in which case they need a separate 32K clock crystal.
Accuracy will be an issue, quality RTC’s use temperature compensated crystals that are also cut to a higher quality/accuracy.
1 Like
So all we’d need to do is to run a firmware that does use it and we wouldn’t have to make any hardware changes?
The STM32 have a dedicated 32.768 kHz crystal for the RTC. But I don’t if it’s temperature compensated (probably yes but can’t verify)… (Where is the BOM???)
What I’m saying is that, materially speaking, everything is there.
For my part, I was able to test a very simplistic implementation (load the RTC, shut down the system, wake up the next day, readback the RTC).
On the STM32 legacy firmware side, add a register for the dedicated peripheral’s RTC, initialise the peripheral (clocks and internals registers).
And from the picomite PoV, add a register set/get on the i2ckbd driver, and route the function of picomite RTC to this register (with proper datas structure conversion).
2 Likes
Just checked the schematic PicoCalc/clockwork_Mainboard_V2.0_Schematic.pdf at master · clockworkpi/PicoCalc · GitHub and it shows a 32KHz crystal X202. If this is fitted then it should be possible to get a reasonably accurate RTC out of the STM32
1 Like
Exactly, just a basic crystal, no temperature compensation at all and unknown quality (they’re only as precise as the cut of the crystal and at a particular temperature)…
I doubt anyone is going to be using their PicoCalc to anything that requires precise timing and anyone who is, will install a proper RTC. The question then becomes, what constitutes good enough? Are we talking about loosing an hour a day or are we talking about loosing a minute a week? The former would be unusable, the latter would not be and there is a lot of room in between those two points.
My experience of STM32 is that the RTC is good for about 30 seconds a day worst case, typically less. However, they have a tuning register function that would let you get it down to < 2 seconds
1 Like
Yes a good question. Yet what do we want a clock for ?, timestamp files correctly, remind us of what day it is, tell the time ?. I for one want to trust the picocalc time, and not have to keep checking and correcting it. If untrustworthy then it’s only a rough indicator. My picocalc is certainly within a second 16 hours after first powering on the added DS3231.
In the real world I rely on an accurate watch that also updates itself 2am every morning with a short wave radio signal from an atomic clock. I use it to set all others around the house and in the car and will be watching the picocalc with it of course.
Back to improving my autorun programs ‘daylight saving time’ correction better… Adding the hour to 23:55 caused an error last night 
.
Without the exact reference of the crystal used, we can’t know the derivation of the timer (the “ppm” value in the crystal datasheet/specs) and the temperature curve too (but if you plan tu use picocalc indoor, I think you should ignore the temperature variation, unless you want a precise clock all the time but without atomic clock reference, it’s just a matter of “time” before loosing timing).
For a 20 ppm crystal, as a month is about 2.3 millions of seconds, you can say that you can have 1 minute deviation after 1 month. For a 100 ppm crystal, 5 minutes for a month.
The 100 ones are very the worst you can find, the 32.768 is generally found between 20-50 ppm.
If you want to be sure, you can always replace the crystal by your own (minus adjusting the load capacitances).
As the STM32 drive the power switch of pico, I planned to use its RTC to setup a “wake-up” sequence everyday at the same time to do some daily stuff.
Using an external RTC could be possible, but it will drain a lot the batterie for “nothing”.
I didn’t make the measure for now, but by simulation, the pico can be still alive 1 month and half (in the worst case) with the 2 fully charged 18650 (3500 mAh) with daily routines including WiFi communication.
The RTC is, after all, a “slow” counter only… You can use it to keep track of elapsed time without needing the precision of the second. (and use the NTP on WiFi, BT or LoRa to keep updated if needed)
I’ll put a “time derivation test” in my list, check how many seconds delta I’ve got.
I am not using my PicoCalc to control a nuclear powered laser to cure cancer patients. I do not need the clock on my PicoCalc to be accurate to within a nano second per year. I would consider 5 minutes per month to be good enough, heck 10 minutes per month would be fine with me.
1 Like
DS3231 done, dusted and soon to be forgotten, shouldn’t need to adjust for a year or so. Wired to the socket pins so doesnt interfere with core swaps. It’s own battery life might be interesting as smaller than usual but easy access. Working happily at 378Mhz and powered from VSYS not the 3.3V.
1 Like
The “wake-up” feature could be really interesting. I’m assuming it could be controlled through I2C like the keyboard backlight, etc.? Then it could be exposed to and controlled by PicoMite (and other firmware too).
I’d be happy with the STM32 solution for RTC, especially if it has extra features like this. I’m planning to keep both batteries in my device anyway, and it would be nice to actually use all that battery power for something, rather than just not having to charge it very often. I’m also not concerned about the time accuracy very much either – seems like a good deal to only have to charge it and query an NTP server once a month. 
1 Like
DS3231 has built in alarms, calibration, aging adjustment, 220uA max current when powered (from PicoCalc 4v Vsys), interrupts, square wave and 32,768Khz outputs, debounced reset input/output and temperature sensor output. No clunky WiFi/NTP server required either hence back to my much faster in all respects Pico2 
. The DS3231 i2C can run at up to 400Khz too (only 10Khz at moment ?). Other variants include 8Mb built in ferro ram with virtually unlimited writes and no need for power backup, a better alternative than PSram !
The F1xxx serie of STM32 have not much features others than RTC, some permanent storage like an external EEPROM for the pico and USB (maybe we can do something about the USB we sacrify the low-power aspect in this case).
I hoped to drive it like some BIOS/UEFI do with a similar “wake-up” mode (triggered by time, LAN even, etc.). That’s the reason why I’m calling it “southbridge” for picocalc.
Sad that the Pico 2 don’t have RTC integrated (only the RP2040 on the Pico 1) too.
No clunky WiFi/NTP but big glued PCB and wires on the back of my PicoCalc, choose your pain! 
Joking aside, DS3231 have more alarms than the STM32F1 (only one) but how can you put the full system in sleep/low-power mode without instruct the AXP or the STM32 to shut-off the power? And after that, how to wake-up from that state if the RTC is plugged on the pico? (maybe through an another wire to one of the GPIO of the STM32 or directly on the power-on signal of the AXP… Yes, yes, I can think of some reaaaaally dirty things when it comes to HW hacking)
I don’t understand why the I2C is locked to 10 kHz… The standard is 100 kHz, 400 for HS-I2C, but 10? I can’t figure why…
The FeRAM can be good on some points like the data retention time, but I read somewhere you need to rewrite after each read. That can be a heavy cons for some usage. For configuration or backlight memory that can be great (instead of an EEPROM), but not for framebuffer or other intensive R/W operations.
That’s why I use a Pico 2W and sync with an atomic clock time server whenever I boot up. I never have to worry about keeping the clock accurate to the second unless I run it for more than 35,000 years. I suspect my batteries will die before then.
2 Likes
Yes but my Pico2 boots in a second now including reading the accurate RTC. I can also clock beyond the 252Mhz limit and have more program space… Its highly unlikely I’ll ever go back as will be a downgrade for me..
Regarding RTC accuracy, the PicoMite (v. 6.00.01) manual says:
“The PCF8563 and DS1307 will keep time to within a minute or two over a month while the DS3231 and DS3232 are particularly precise and will remain accurate to within a minute over a year.” (page 51, Real Time Clock Interface)