Why ST keep implementing RTC as calendar instead of RTC binary counter?

[PSoco.1]

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.

[waclawek.jan]

https://community.st.com/s/question/0D53W00000ghPs9/have-you-noticed-the-binary-mode-of-rtc-v3

You can consider also to add it as an Idea (although ST ignores those, too).

JW

[TDK]

One issue with a 32-bit Unix timestamp is there is no easy way to convert it to a month/day/year without a library. And typically the user wants to see the date in year/month/day form instead of seconds since 1970.

[PSoco.1]

@TDK you do not need an HW to get date time from posix timestamp. if you have to chose between a trivial HW that works with trivial driver and datetime conversion library, or, complex HW and complex driver and you still need the exact same datetime conversion functions... tell me where is the benefit on the latter.

[PSoco.1]

I just believe that this has been kept like that for historical reasons. RTC cell probably is so old that crosses that epoch where there was a belief that HW should to complex operations. like for CISC and RISC, RISC has better overall performance but we still use x86 CISC architecture due to compatibility. or maybe ST don't see the benefit of reviewing something that always worked that way. Luckily we can still choose other manufacturers next project :>

[TDK]

> you do not need an HW to get date time from posix timestamp.

But then you do need software. Having it done in HW eliminates that problem, especially for chips with very limited FLASH. You asked for a reason, I gave you one.

Doubt you're going to influence the HW design hardware here. Having a different RTC on the H7 vs the other families seems like a poor solution to a problem that doesn't exist.

[waclawek.jan]

> RTC cell probably is so old

Actually, the first RTC version on STM32F1 is just a 32-bit counter.

Then there's an idiotic calendar implementation in the "libraries", which converts only time, and keeps date in a backup register, incrementing it when detecting midnight crossing...

JW

[PSoco.1]

@TDK I said a good reason, not any reason. About the amount of software you may get away with that only if you do not need conversion library, my point is that most software do convert them. we see more and more timestamps used in IoT and security in general. So larger MCU with security should provide RTC counter interface. Then about each family having different version of the same HW is a very common thing. maybe my suggestion is too radical for the moment, but NXP, Atmel and more they provide counters. About being a problem, I didn't say it is a problem, I am saying there is no benefit on larger MCU to have calendars. we do not share the same perspective, I am ok with that, but you were just mean with your answer. if you don't share just be cool man.

>Doubt you're going to influence the HW design hardware here.

Nobody expects ST listen.

[PSoco.1]

@Community member​ thanks I see I am not the only one frustrated with this nonsense

[PSoco.1]

I will check it