The RTC driver topic

[DrunkenDonkey]

Great, thanks, I looked at the example and it is wonderful, I won't need it for many more months, but will do for sure

[brian360]

Wow, thank you, too! I'll surely be integrating the RTC driver into my project quite soon, too, so it's good to see other people interested as well.

[barthess]

Nice to see that someone needed the results of my work. You can help too.
As you can see, English is not my native language. If anybody can rectify and(or) improve my doxy comments in code than spent some time to send me patches.

[DrunkenDonkey]

Having same problem with the English
barthess, I'm using another of your development too - the I2C driver, I still haven't even received my board, but hopefully one day I'll be able to contribute too.

I'm sure this is not the place, but it somewhat related - sleeping/waking up... can the cpu wake up from serial data properly without breaking chibi somehow, like it wakes from the RTC? And not lose like half of the data, more like first sync byte?

[Giovanni]

Not sure but it is possible that the UART RX can also be programmed using EXTI, the descending front of the start bit can be used for wakeup. The reference manual could give an answer (making it work would be the definitive answer...).

About the RTC driver, it looks good but probably the use of the methods rtcStart() and rtcStop() is not appropriate. In general the methods xxxStart() and xxxStop() are used to stop and start a driver and change the driver internal state, the RTC is really never stopped and the driver is stateless. The methods are just used to associate a callback or disable it.

I would recommend to not have rtcStart() and rtcStop() at all but introduce something like rtcSetCallback(), passing a pointer would enable the callback, passing NULL would disable it, the callback pointer would reside in the RTC driver structure, there would be no configuration structure at all, all the eventual configuration would be static. The only other stateless driver so far is PAL, it does not have start and stop methods either.

Giovanni

[barthess]

DrunkenDonkey:
Like noted by Giovanni, it is possible using EXTI line. But remember, deepsleeping is something very close to power off. You must give some amount of time to your MCU to startup, to stabilize oscillator and so on, and so on. Consult with part 4.3 of manual.
Anybody measured time after power on to entering in main() function? How much time that take?

[Giovanni]

It varies, the crt0 has to initialize DATA and BSS so it depends on the application data size. The PLLs stabilization time should be considered too.

The first data frames would be lost for sure but the protocol could be designed to retry after a timeout and resend the frame.

Giovanni

[barthess]

Also possible to sleep not too deep:
Slow down main clock, disable (almost) all peripherals except UART and switch on WFI hook in Idle thread.

[barthess]

to not have rtcStart() and rtcStop() at all but introduce something like rtcSetCallback(), passing a pointer would enable the callback, passing NULL would disable it

It is more elegant solution. Code changed, examples updated (rev. 3284).

[barthess]

Need some help from C/C++ professional. To make driver size (compiled) smaller I have try to use conditional compilation.
in rtc_lld.c

Code: Select all

  #if RTC_CLOCK_SOURCE == RCC_BDCR_RTCSEL_LSE
    //LSE code here
  #elif RTC_CLOCK_SOURCE == RCC_BDCR_RTCSEL_LSI
    //LSI code here
  #elif RTC_CLOCK_SOURCE == RCC_BDCR_RTCSEL_HSE
    //HSE code here
  #else
    #error "RTC clock source not selected"
  #endif

in halconf.h

Code: Select all

#define RTC_CLOCK_SOURCE            RCC_BDCR_RTCSEL_LSE

rtc_lld.c code cause following compilation error: "missing binary operator before token "0x00000100"". Looks like problem in definition style in stm32f10x.h

Code: Select all

#define  RCC_BDCR_RTCSEL_LSE                 ((uint32_t)0x00000100)

preprocessor can not understand explicit casting to uint32_t.
Are there any workarounds?