The RTC driver topic

[barthess]

API redesigned. Code moved to ./os/hal/platforms/STM32/RTCv1 and tested on STM32F103.
All functions take pointer to platform specific RTCDateTime structure defined in low lovel part.
What to do with overflow callback? Are there some equivalent on other platforms?

[Giovanni]

Hi,

I am going to write an implementation for the STM32L, just to double check the API is general enough. I'll be making documentation related changes too.

Giovanni

[Giovanni]

HI Barthess,

I have some more feedback. I think that the function rtcSetCallback() should become:

rtcSetCallbacks(RTCDriver *rtcp, const RTCCallbacks *rtccp);

The rationale is that the current callbacks are STM32F1xx-specific and not necessarily found in other devices, so better put the callbacks into a structure defined in the low level driver, this would also save RAM space because in RTCDriver you will only have to put a single pointer to RTCCallbacks.

The newer STM32 devices (L, F2 and F4) do not have callbacks anymore, they use dedicated EXTI lines so the user will have to use the EXT driver in order to have callbacks, RTCCallbacks would be empty and rtcSetCallbacks() would have no effect.

Another new feature found in new RTCs are two distinct alarms, probably we should put an extra parameter to the rtcSetAlarm() and rtcGetAlarm() in order to support this, the functions should also receive a pointer to the driver, we cannot assume there is a single RTC in the system:

void rtcSetTime(RTCDriver *rtcp, RTCDateTime *timespec);
void rtcGetTime(RTCDriver *rtcp, RTCDateTime *timespec);
void rtcSetAlarm(RTCDriver *rtcp, rtcalarm_t alarm, RTCDateTime *timespec);
void rtcGetAlarm(RTCDriver *rtcp, rtcalarm_t alarm, RTCDateTime *timespec);

rtcalarm_t is an unsigned scalar, the low level driver would export a macro RTC_ALARMS with the number of the available alarms, if RTC_ALARMS == 0 then the high level driver will disable rtcSetAlarm() and rtcGetAlarm() in order to save space.

If you are busy I can do the changes myself when I will implement RTC in STM32L/F2/F4.

Giovanni

[barthess]

Hi Giovanni,
I'm a little busy right now. In addition, I have no possibility to develop and test new driver model on platforms other than STM32F1x, so go ahead and change the API, as you see fit. Do not forget to post news in this topic when it will done.

P.S. are there any MCU with more than 1 RTC?

[Giovanni]

Don't worry, you already did far more than one could reasonably expect and I was planning to implement STM32L/F2/F$ RTC drivers myself anyway.

I don't know if there are MCUs with more than one RTC but I don't see a reason to preclude such a possibility, we just need to follow the usual HAL functions rules.

I will post here any change to the RTC driver model or implementation for you to evaluate.

Giovanni

[Giovanni]

Hi Barthess,

I finished the changes on the RTC driver, the changes:
- Different structures for time and alarms, usually alarms don't use the same format of date/time.
- Unified callback with an "event" parameter, the parameter is platform dependent.
- Alarm APIs modified to allow multiple alarms where possible.
- Alarm APIs only enabled on RTCs supporting alarms.
- Callback is no more configurable, it is always present on RTCs that have callbacks not present on RTC not supporting interrupts.

I also modified the initialization procedure, there was a possible error: selection of the clock source before the initialization of the clock source. Anyway, probably clocks initializations should go in the HAL driver but I haven't implemented this yet so it is still in the RTC.

I need your feedback, I am not sure how to test it properly, I don't have any board with a battery.

Giovanni

[barthess]

I will test it on sunday

[barthess]

Hi Giovanni,
Driver works fine. Some feedback:
1. What is it alarm identifier? I am understand that it not uses on STM32F1x but it would be good to have some more description in documentation.
2. Line 148 of rtc_lld.c "TODO: Change this code, software loops are not reliable." Why it is not reliable?

Also I founded strange bug not described in hardware errata.
If I use "monitor reset halt" instead of "monitor soft_reset_halt" command to start debug session than RTC->PRLx resets to its default value. Reset button and poweroff are not reset RTC->PRLx. I do not use "monitor soft_reset_halt" because it not always can halts MCU.

[Giovanni]

Hi,

1) Agree on the documentation, some RTCs have multiple comparators, for example the newer STM32x have two comparators instead of one.
2) It could (and probably is) optimized away from the compiler, the variables are not declared volatile. Anyway, it is possible that the delay is not really required, activating the RTC while the clock is not yet stable should have no consequences, you just have to make sure that rtcSetTime() is called after a decent delay. Also, being the internal oscillator probably the precision is not a factor at all.

About the other problem, may be it is an OpenOCD issue?

Since the driver works I'll try to make an unstable release tomorrow.

Giovanni

[barthess]

About the other problem, may be it is an OpenOCD issue?

My be. It is not a fatal bug. Just to other users to know.

I am not sure how to test it properly, I don't have any board with a battery.

You can easily upgrade board by direct soldering lithium battery to correspond pins, like I am on my STM32-103STK from Olimex.