Page 5 of 23
Re: RTC driver
Posted: Sun Oct 09, 2011 3:14 pm
by mabl
Hey,
thanks for the RTC driver. Works fine for me
Just some curious questions though:
Couldn't it happen that seconds wrap just after the ms are read? Also, the same problem applies for the DIVH register. Could rtc_lld_get_time be adapted to handle such problems like
Code: Select all
void rtc_lld_get_time(RTCDriver *rtcp, RTCTime *timespec) {
uint32_t time_frac;
uint16_t second_guard;
(void)rtcp;
do{
second_guard = RTC->CNTL;
time_frac = (((uint32_t)RTC->DIVH) << 16) + (uint32_t)RTC->DIVL;
timespec->tv_msec = (uint16_t)(((STM32_LSECLK - time_frac) * 1000) /
STM32_LSECLK);
timespec->tv_sec = (RTC->CNTH << 16) + RTC->CNTL;
}while(second_guard != RTC->CNTL);
}
On a related note: What about the year 2038 problem? I know that none of our hardware will probably be around by then, but you never now... Could there be a build switch added which increases the seconds counter to uint64_t and increase it by 2^16 when RTC_EVENT_OVERFLOW is called?
Also, i think with an addition GPT one could increase the precision of rtc_lld_set_time to also include milliseconds. Could be worth a build switch too?
Re: RTC driver
Posted: Sun Oct 09, 2011 5:20 pm
by Giovanni
The problem is that you CPU could not be active to handle the interrupt. The application could test the last date on startup and verify if it wrapped.
Giovanni
Re: RTC driver
Posted: Sun Nov 13, 2011 11:47 pm
by Xamusk
mabl wrote:On a related note: What about the year 2038 problem? I know that none of our hardware will probably be around by then, but you never now... Could there be a build switch added which increases the seconds counter to uint64_t and increase it by 2^16 when RTC_EVENT_OVERFLOW is called?
Also, i think with an addition GPT one could increase the precision of rtc_lld_set_time to also include milliseconds. Could be worth a build switch too?
Maybe not you, but I do intend to have hardware working properly after 2038. Embedded systems usually should last for the lifetime of where they are embedded into. Even though these days even electronics seem disposable, some systems like transportation systems can be used for a long time before being retired. Maybe even a nuclear reactor controller?
I wouldn't want it to fail.
Maybe we could just have some sort of variable epoch. This way, the system could run for 135 years without problems. The conversion to a 64-bit value could be just with the getter function, or even outside it.
Re: RTC driver
Posted: Sat Dec 10, 2011 4:06 pm
by mabl
Hi barthess,
I just stumbled over two bugs in the RTCv1 driver:
Code: Select all
void rtc_lld_get_time(RTCDriver *rtcp, RTCTime *timespec) {
uint32_t time_frac;
(void)rtcp;
time_frac = (((uint32_t)RTC->DIVH) << 16) + (uint32_t)RTC->DIVL;
timespec->tv_msec = (uint16_t)(((STM32_LSECLK - time_frac) * 1000) /
STM32_LSECLK);
timespec->tv_sec = (RTC->CNTH << 16) + RTC->CNTL;
}
- The milliseconds are calculated with the assumption that RTC Clock is LSE which will fail for other clock sources.
- And less serious but it should be documented: Milliseconds will be equal to 1000 if time_frac is zero.
MaBl
Re: RTC driver
Posted: Sat Dec 10, 2011 8:44 pm
by barthess
mabl wrote:- The milliseconds are calculated with the assumption that RTC Clock is LSE which will fail for other clock sources.
- And less serious but it should be documented: Milliseconds will be equal to 1000 if time_frac is zero.
Fixed.
Re: RTC driver
Posted: Sun Dec 11, 2011 8:15 pm
by barthess
I am working on RTC porting to F4x. Setting and getting time works now. Any volunteer may check out
https://chibios.svn.sourceforge.net/svn ... es/rtc_dev and test it.
Giovanni,
1. L1x, F2x, F4x have hardware calendar.
2. F1x have simple 32bit counter.
3. F1x, F4x have subsecond ability.
I do not know how to organize code. Having a bunch of identical drivers in different HALs looks like bad idea.
Re: RTC driver
Posted: Sun Dec 11, 2011 8:26 pm
by Giovanni
I would divide those in two groups RTCv1 (F1) and RTCv2 (L1, F2, F4), differences in v2 could be handled by adding a capability to the HAL: STM32_RTC_HAS_SUBSECOND or similar.
Giovanni
Edit: added STM32_ prefix, all macros should have it.
Re: RTC driver
Posted: Mon Dec 12, 2011 9:24 am
by barthess
Giovanni
All RTC (and not only RTC) interrupts in F4x routed on EXTI cell. So user can unintentionally switch off interrupts during startup of EXT driver from him code ({EXT_CH_MODE_DISABLED, NULL}, just to be safe). My suggestion is to setup only [0..15] channels in ext_lld_start(). Other 16th and later channels can be setup manually by ext_lld_channel_enable(). What you say?
Re: RTC driver
Posted: Mon Dec 12, 2011 9:45 am
by Giovanni
Probably it is a good idea, it would also make the configuration structure equal on all variants.
I am not sure what the EXT driver should do with channels >=16, do not initialize them or set them to disabled by default? Do not initialize them could be dangerous too.
Giovanni
Re: RTC driver
Posted: Mon Dec 12, 2011 10:03 am
by barthess
I think, do not touch them at all because they are disabled by default.