ChibiOS Free Embedded RTOS

Simply do not use constants from the ST headers, define your own.

In halconf.h there should be nothing STM32-specific, those should go in mcuconf.h.

Giovanni

Defines moved to hal_lld_xxxx.h. Halconf.h in RTC test updated.

Hi Barthess,

I have a suggestion about the RTC driver: Instead of having two functions rtcGetSec() and rtcGetMsec() we should just have "uint32_t rtcGetTime(uint16_t *msec)".

The rationale for this:
- One less function.
- It is symmetrical of rtcSetTime().
- It allows to get atomically both seconds and milliseconds, two functions do not allow atomicity and there can be an error up to one second.

I also suggest to allow NULL as parameter if the caller is not interested in milliseconds.

Giovanni

how about:
uint64_t rtcGetTime();
return microseconds since UNIX epoch

It would be nice but uint64_t is not supported by all compilers, the driver model should be usable even with 8bits micros, uint32_t is already troublesome in that context.

Giovanni

Your variant is more portable -- realized in code and tested rev. 3376
Just to know, what compilers not support uint64_t?

The STM8 compilers, both of them, those don't even support C99.

Giovanni

Hi,

I wanted to test the RTC driver on the STM32L and realized that the RTC hardware is totally different on STM32L, STM32F2 and STM32F4, apparently the current implementation is good for the STM32F1x only.

It should be relocated under ./os/hal/platforms/STM32/RTCv1

The second problem is that the new RTC uses a whole different concept, there is not a single counter but a series of fields representing years, months, days, day_of_week, hours, minutes, seconds and a sub-second counter. I think the current RTC driver model do not work week with the RTCv2, the driver would have to convert the BDC date/time into an absolute time then the application would have to convert it again in BDC or ASCII. I checked other families, LPC17xx and STM8L also uses a BDC date/time format which is apparently more common.

My suggestion: make all the function work with a struct "RTCDateTime" whose fields are architecture dependent, not imposed by the RTC driver, this way the driver will never have to make conversion internally. The RTCv1 would have 2 fields equivalent to the current function parameters.

Giovanni

Hm... hardware calendar is really nice feature, especially comparing with software realization from <time.h> that require about 30kb of flash and about 700 bytes of stack.

It should be relocated under ./os/hal/platforms/STM32/RTCv1

Please, explain naming convention.
How you suggest to unify high level interface?

My suggestion is to not use uint32_t uint16_t like in the current implementation, we should define a structure RTCDateTime whose first field is a time stamp in DOS format and is mandatory, in addition there can be more implementation dependent fields containing info like:
- DST flag.
- Day of Week.
- Sub-second counter.
- etc

Probably the DOS format is the most convenient one, it is easy to make conversions.

Probably also the alarm should have a similarly defined structure named RTCAlarm with a DOS date/time inside plus more optional fields.

Giovanni