The RTC driver topic

[Giovanni]

RTCDateTime should be the "standard" format, we can create a library with conversions to/from other formats but not like the old library, it would be portable and not filled of #ifdefs.

Code: Select all

Just a curious. Can you remember how rtc ISRs worked without EXTI in v-2.6 testhal?

I am not sure to understand the question, RTCv1 had its own callback, RTCv2 relied on the EXT driver, is this correct?

Giovanni

[barthess]

RTCDateTime should be the "standard" format

Totally agree.

we can create a library with conversions to/from other formats

Why separate library for 4 conversion functions? This functions will be without #ifdefs at all.

RTCv1 had its own callback, RTCv2 relied on the EXT driver, is this correct?

Now I am in doubt. I can not obtain interrupts from RTCv1. I definitely need to go deeper. Forget about this question.

[Giovanni]

Why separate library for 4 conversion functions? This functions will be without #ifdefs at all.

In order to keep the driver lightweight, it is not like you need multiple formats in the same application, ideally you can use RTCDateTime directly. The only other format planned in rtc.c is the DOS formate because file systems require it.

The only thing I would like to add is a function that converts from RTCDateTime to a readable string.

Giovanni

[barthess]

In order to keep the driver lightweight, it is not like you need multiple formats in the same application, ideally you can use RTCDateTime directly.

On platforms with simple counter you need this functions in any way. On other platforms this code will be eliminated by linker. So I do not think that having such conversion functions in rtc.c is bad idea.

[Giovanni]

I am worried about excessive dependencies on libraries, not all compilers are fully compliant, see the various dumb compilers for 8 bits MCUs.

I removed lock/unlock from the high level driver and moved the critical zones into RTCv2 using the new 3.0 API, the new API allows to make critical zones usable in both thread and ISR context, you may do the same in RTCv1.

Giovanni

[Giovanni]

Barthess, I saw you updated the driver, shouldn't the DOS conversion function consider the DST flag too?

About the other conversions, go ahead and implement the conversions you need, we'll eventually add a switch in case of problems.

Giovanni

[barthess]

shouldn't the DOS conversion function consider the DST flag too?

Looks like it should.
https://bugs.launchpad.net/ubuntu/+sour ... bug/612292

FAT32 stores timestamps according to the local wall-clock time, not UTC

I will fix it and finalize RTCv1 this weekend.

About interrupts from RTCv1. I forgot about separate vector in NVIC. Now it works.
But awakening from deep sleep on alarm still does not, looks like I forgot something
very obvious.

[barthess]

Conversion functions in rtc.c(h) did not me happy because of circular dependencies.
I think your idea about chrtclib is better than mine. What about moving of
rtcConvertDateTimeToFAT() and RTCDateTime typedef to the chrtclib?

[Giovanni]

OK, lets try that.

Giovanni

[barthess]

I committed files. Please take a look at them when you have some spare time.
I am also performed some benchmarking. Results in ticks are:
rtcGetTime ~3000
rtcSetTime ~54000

UPDATE:
Where is realtime clock frequency defined?