Why ST keep implementing RTC as calendar instead of RTC binary counter?
I am not an ST expert nor RTC expert, whatever that means. but I have seen several implementations made by other companies and I have to say RTC as counter (the HW that provide interface to a posix compatible timestamp, usually 32 bit seconds + 15 fractional bits) is faster (at driver level the posix time value is written and read without conversion to expanded form), math friendlier (non trivial time calculation is really hard in expanded form so everyone tends to use posix form converting it) and I suspect since the lower amount of transistor, much simpler, lower power and cheaper. I never liked the RTC calendar HW implementation since it is overcomplicated in both HW and driver and I cannot see any benefit on such implementation. I understand that calendar implementation make sense 30 years ago on 4 bit processors when RTC was mainly used to produce a digital clock; now today cpu are used mostly for IoT and other device that are not just a simple clock printing the date/time over 7 segment LED display, they do calculation so conversion take place often, usually way too often removing any benefit from having HW calendar. can someone name a good readon to stick with calendar HW implementation? why STM32 keep feeding us an RTC calendar in a STM32H7 with CM7 @ >500MHz? thanks, if someone can provide any good reason about this nonsense. by the way, truly love STM32H7, amazing CPU amazing feats, and maybe because I love it, I spend the 10 minutes asking about this odd implementation choice. hope to see in the future a review on ST RTC, a combined calendar + counter so that ST can make happy both users, or maybe better, just ditch the calendar, since with HAL drivers customer won't notice the upgrade, and those do not use HAL will be happier to develop a much simpler and trivial driver.
