Page 19 of 23

Re: The RTC driver topic

Posted: Wed Oct 29, 2014 7:54 pm
by 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

Re: The RTC driver topic

Posted: Wed Oct 29, 2014 8:04 pm
by barthess
Giovanni wrote:RTCDateTime should be the "standard" format

Totally agree.
Giovanni wrote: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.
Giovanni wrote: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.

Re: The RTC driver topic

Posted: Wed Oct 29, 2014 9:03 pm
by 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

Re: The RTC driver topic

Posted: Wed Oct 29, 2014 9:27 pm
by barthess
Giovanni wrote: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.

Re: The RTC driver topic

Posted: Thu Oct 30, 2014 3:27 pm
by 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

Re: The RTC driver topic

Posted: Fri Oct 31, 2014 10:48 am
by 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

Re: The RTC driver topic

Posted: Fri Oct 31, 2014 11:26 am
by barthess
Giovanni wrote: 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.

Re: The RTC driver topic

Posted: Sat Nov 01, 2014 12:00 pm
by 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?

Re: The RTC driver topic

Posted: Sat Nov 01, 2014 12:56 pm
by Giovanni
OK, lets try that.

Giovanni

Re: The RTC driver topic

Posted: Sat Nov 01, 2014 2:26 pm
by 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?