Pet peeve of the day: MCU families that obviously share common IPs (e.g. GPIO blocks, SPI blocks, etc with the same SFR definitions across multiple parts) but don't go out and say it.
So I take code I wrote for one chip and it might port seamlessly to another, but I don't know until I line-by-line compare the datasheets to see if all the registers are the same.
Also, it bloats docs by having a bazillion copies of the definitions of each IP's register in each chip reference manual.
What I'd much prefer is a top level datasheet for each chip that contains the memory map, pinout, and any chip-specific config like peripheral clock enable registers.
Then just have the memory map say "0x4000_1800 is GPIOC, this a GPIOv3 IP" and link to the GPIOv3 datasheet.
@azonenberg It would be nice if someone would just cast a 64b millisecond counter that can be atomically read and written to silicon and purge the 1970s RTC clock from silicon libraries. Ok. Maybe a microsecond counter. But having to stop the clock, break time into years, months, days, hours, and minutes then having to wait until second are 00 to restart the clock is ludicrous. Geez it is 2024!
@bscloutier As far as time goes, for PC stuff in e.g. libscopehal I use 128-bit timestamps (int64 seconds since 1970 epoch, int64 femtoseconds since the UTC second).
@azonenberg The Renesas RX takes the year as a word so 4 digits. But this is no doubt an unnecessary variant of the late 1960s original digital watch silicon. Likely public domain library now but originally proprietary. Everybody stole everything back then. No different now I assume.
So we have to go through the exercise of converting between that RTC and the unix timestamp either in writing or reading if you want to have a non-volatile clock.
The STM32 RTC is BCD internally so year tens, year ones, minute tens, minute ones, etc. are all separate nibbles.
Then there's a sub-second register that counts at some convenient frequency (10 kHz in my current configuration).
I actually have three different time formats to worry with in my code: NTP format (seconds and fractional seconds since an epoch, but it's not 1970 epoch), Unix time as expected by libc, and then the native RTC format.
Good news is, for now the conversions are one-way (I only use the RTC timestamp for display and never have to convert it back to a time_t or a NTP timestamp).
@azonenberg Seems dumb. If they replace that in the silicon with the 64b counter it not only would be simpler for us but would open up some acreage for them.
As it is it limits the resolution of the clock through power down periods. Not that the RTC is that accurate to begin with.
I let NTP update both the system clock and the RTC. The OS actually can fine tune the osc at that point so that both clocks stay in sync eventually. My DATE command has an option to display both clocks as a check.
@bscloutier Yeah I don't have a "system clock" per se on this platform, I just use the RTC directly.
Running a software PLL to correct for local oscillator drift is absolutely possible, but with my current accuracy I haven't seen the need for that. (I don't have a battery and run the RTC off of the main 25 MHz system clock).
But yes I agree, having a time_t plus sub-second counter in hardware would make more sense.
@azonenberg if you can't read that RTC atomically then there is the risk of rollover errors as you collect the various registers. Obviously you can't stop the thing everytime you want to read it.
Lots of fun ain't it? Meanwhile the important stuff demanding your attention just sits.
You can read the RTC atomically-ish via shadow registers that lock once you read the first one.
But there's no access to the sub-second counter when you do that.
So if you want high precision time you have to read all of the registers in order from sub-second up to the year, then read the sub-second counter again.
As long as the new value is bigger than the old it didn't wrap, so the values are good.
If it's smaller it wrapped, so read again and it should be good from there on out (as long as your second read is <1 sec after the first, there's no chance of a carry-out from any of the registers).
@cccpresser Yeah I recall there being a family datasheet with sections for peripherals, I just dont recall versions of the IP being explicitly documented (so that e.g. you'd know if the MX300 and MZ200 series had the same GPIO block).
on another hand - hey, at least you have a bunch of info on it, RK3399 reference manual is only ~1100 pages, and it's a pretty damn thick SoC, it should have waaay more information on it - but it doesn't.
Add comment