The RTC driver topic

[barthess]

rev. 3983
Test suit done, planned functionality done. I am in doubt about 2 things:
1) time format (12 or 24 hours) through the FMT bit in the RTC_CR register
2) If the frequency of the APB1 clock is less than seven times the frequency of RTCCLK, than we must use 3-read workaround.
Are they really need?

[Giovanni]

Could 12/24 be a configuration option?

About the clock issue, I would just add a compile time check and give an error if the condition is not satisfied, no need to implement that 3 reads stuff.

Giovanni

[barthess]

1) Realization of 12/24 compile option turns too ugly. I added boolean flag to RTCTime structure.
2) Compile time check added.

UPDATE:
I think the code is ready to style polishing.

[Giovanni]

Hi Barthess,

I will give you feedback ASAP, this is one of those "bad weeks" because job deadlines

Giovanni

[barthess]

this is one of those "bad weeks" because job deadlines

I have the same troubles

[barthess]

Hi Giovanni,
Do you have any plans about RTC development on this weekend?

[Giovanni]

Hi Barthess,

I am not ignoring you , this weekend I will review the driver.

I had 5 distinct meetings just today, bad week...

Giovanni

[Giovanni]

Hi barthess,

I reviewed the driver, good work it looks mostly OK as code style, it could be merged.

I have few questions unrelated to style:

1) The field "cb_cfg", it is no more used right? if so we could simply remove it. We can mark it as "optional" in the driver template.

2) Conversion from/to Unix time is not required in the driver, it could become a library module. I understand your idea to have a common time/date format but I am not sure the Unix time would be the best choice, the user would have to convert it to calendar format again anyway. If we decide to create a standard format probably that would have to be calendar-like, most RTC I saw are calendars, the STM32F1 RTC is the exception. Another point is that RTC data would be required by FS modules and those require a DOS data/time which is calendar-like.

3) Is the driver written to be compatible with L1/F2 and F4? I could test on the L1 but not on the F2 yet.

Giovanni

[barthess]

1) deleted
2) If you about functions stm32_rtc_tm2bcd() and stm32_rtc_bcd2tm() they are convert not to unix time (integer counter, if I understand correct) but to calendar like structure defined in <time.h>. I placed it in driver code because they convert from STM specific representation to standard format.
3) driver written with compatibility in mind, but I can test it on F4 only.

[Giovanni]

OK, understood. I don't like to depend from time.h because it is possible other compilers don't have it. While we think about this you may merge the driver and the test application if you are ready, we will handle it in the trunk from now.

Giovanni