The RTC driver topic

[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?

[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

[Xamusk]

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.

[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

[barthess]

- 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.

[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.

[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.

[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?

[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

[barthess]

I think, do not touch them at all because they are disabled by default.