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.

[TDK]

> I am saying there is no benefit on larger MCU to have calendars

There's no benefit for RTC library/register compatibility between families?

> you were just mean with your answer

I did not intend to come across harshly. Just trying to be objective. Apologies if I was harsh.

[PSoco.1]

>There's no benefit for RTC library/register compatibility between families?

There is big benefit, but you will never get 100% compatibility, especially when you cover a broad range of applications, there is why you end up using HAL. now for RTC the result is exactly the same anyway, and as @waclawek.jan pointed out there are other smaller families using RTC counter. Now smaller controller you want calendar instead as you pointed out, but ST gives a counter. and on larger 'secure' (not even close to a secure uC, but has accelerators and features used in IoT) uC like STM32H7Bx you get a calendar instead of a counter... which is confusing...

>I did not intend to come across harshly. Just trying to be objective. Apologies if I was harsh.

no worries, it happens

[waclawek.jan]

> problem that doesn't exist

Calendar mode is good only for trivial local timekeeping. I don't say it does not cover much of the RTC usage, but anything beyond that is a PITA, would that be support for multiple timezones, less-than-trivial DST, variable-time wakeup, or non-realtime-applications of RTC. These all are existing problems.

> There's no benefit for RTC library/register compatibility between families?

The switchable binary/calendar as it is in that 'WL55-exclusive v3 RTC I referred to above, is compatible. IMO better spent transistors than the ever-worsening wreck SPI is, and some of the other not-very-well-thought-over "improvements" in other IPs.

JW

[PSoco.1]

> The switchable binary/calendar as it is in that 'WL55-exclusive v3 RTC I referred to above, is compatible

Sorry, I am not sure I got that. Do you mean the RTC v3 as both binary and calendar implementation?

[PSoco.1]

I just checked, it is a calendar, you can get BCD encoding, but you still need a conversion to get the counter

[waclawek.jan]

If I undrstood it correctly, you chose whether to use it as Calendar or as a Counter, and then stick to it; i.e. there's no hardware doing the conversion.

Yes, it would be better to have both in parallel, maybe gateable to decrease consumption, plus a few bits to choose which one would be used for the Alarms; but ST is not famous for their IP designers to understand practical usage of their products (see already mentioned SPI).

JW

[PSoco.1]

Hi,

> If I undrstood it correctly, you chose whether to use it as Calendar or as a Counter, and then stick to it; i.e. there's no hardware doing the conversion.

yes, you get one interface or the other. competitors on larger machines with security do provide a very high quality counter, usually HW protected that takes the form of a Secure RTC because tampering the XTAL would trigger violations and potentially switch to internall RC. ST provide some violation signal to do something similar an I can see they are doing progress. but not in the right direction.

> Yes, it would be better to have both in parallel, maybe gateable to decrease consumption

A double/mixed interface is hard to implement correctly because of the way it works internally, when I did suggest dual implementation I meant two separate timers completely isolated. (competitors do put two timers, the counter form is so lean that having an extra one is not a big deal)

Althoug I would have never used the calendar form.

Just to make sure other people understand what is this about, there are several benefits of using unix timestamp and if your rtc counter is just a simple timer with a single 32 bit register that increments each second you can read the timestamp in a single atomic operation, the driver cost would be initialization, but for read the timestamp is a single instruction (few more considering fetch the source address and jump)

so assume you need the timestamp you will have an hypothetical TimestampNow() function that simply reads the register, the cost is one direct read. you can make TimestampNow inlined if you want.

you can run TimestampNow() in interrupt, because it is extremely fast.

let say you have an alarm function that grabs the timestamp and saves that in a 32bit register, TAMPER module in STM32 RTC3 does that. if you want to tell the user when this happend you do this:

uint32_t elapsed_seconds = TimestampNow() - AlarmValue();

you can divide by 60 to get minutes, 60 again to get hours, 24 again to get days and so on. the timespan would be with just a single integer subtraction, some divisions if you want to print it.

I can carry on all day giving examples of how to work with timestamps... you cannot do that with a calendar "struct" as it takes dozens operations at the very best and is easy to get it wrong. so in any smart software you always convert to timestamps. converting in one way and the way back is not that hard, but it has some divisions in the middle which are notorious to take some time to complete. you do not want to use it in your interrupts.

So if you get a calendar you tend to not use it in interrupts.

you could have a very fancy UI and put in your main

for(;;)
{
if(vertical_sync())
refreshUI();
//main loop things
}
[...]
 
static uint32_t last_timestamp;
void refreshUI(void)
{
if(TimeStampNow() != last_timestamp)
{
last_timestamp = TimeStampNow();
update_clock_label();
}
}

you may notice the update does not need a timer, a semaphore or anything. just a backup copy to detect when the clock just changes, it updates automatically each screen. if you are smart enough you use timestamps, even if you have to print it in your UI...

adding a warning would be trivial and extremely fast too... the warning could prin how long you have been disconnected. I

static uint32_t last_time_connected;
static uint32_t last_timestamp;
void refreshUI(void)
{
if(TimeStampNow() != last_timestamp)
{
last_timestamp = TimeStampNow();
update_clock_label();
}
 
if(!IoTConnected())
{
uint32_t check_how_long = TimeStampNow() - last_time_connected;
if(check_how_long > (5 * 60))
{
//after 5 minutes show you are not online, wireless will keep retry connecting
update_warning_label();
}
}
else
{
remove_warning_label();
}
 
}

hope people get the idea... if you keep using this strategy you will notice that timestamp is being called hundreds of times per second. now just add a conversion function each read of the HW timer and you get an additional (at least) 2 divisions and several additions, subtractions and moltiplications. so what you do? you read the timestamp once, convert it, initialize a backup counter in RAM and increment it each second, possibly in interrupt. so now you use another timer because the first one is flawed. yeah, and the timebase usually works in milliseconds so you have to add a software prescaler that counts to 1000 to count seconds. all this to emulate an RTC counter... and I bet most if not all people do this, but never paid too much attention on the irony of using a second timer because the first is badly implemented.

next step is, if you have a integrated security coprocessor that manages the keys for you (a truly secure uC), then the timestamp must be available in HW so that you can generate a permission token without the software ever accessing the RTC register for read or write. since we moves towards a world where small devices connect to internet hope to see ST waking up...

[waclawek.jan · Accepted solution]

What guidance do you need exactly? This is only a hypothetical "what if" thread. The RTC is implemented in the way it is, just face it.

JW

[PSoco.1]

Yes waclawek.jan is correct, if you need to use RTC do not start from this thread. my rant is on the weak criteria of uC design. The RTC does its job (maybe not the way all of us like it) check SDK on how to use it.

• how do you close the thread? I am new to this forum...

[waclawek.jan]

> how do you close the thread?

Only Moderators can do that.

Btw., did we contemplate the option of using TIM/LPTIM for timekeeping? Yes, it has its (severe) limitations, and available only in some STM32 families, but still.

JW