The RTC driver topic
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: The RTC driver topic
I agree, there would be one implementation for each driver, but luckily most RTCs are of the calendar type, the STM32F1 is an exception apparently.
Giovanni
Giovanni
Re: The RTC driver topic
I propose to realize own code for "smart" MCUs and keep as is for F1x. Do you agree?
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: The RTC driver topic
Let's address the F1 last, how would you modify the driver model?
The minimal functionality required is to support the FS, everything else can stay outside the driver.
Giovanni
The minimal functionality required is to support the FS, everything else can stay outside the driver.
Giovanni
Re: The RTC driver topic
Why driver model? Just add #ifdef STM32_RTC_IS_CALENDAR in rtcGetTimeFat() function.
Re: The RTC driver topic
Can we add compiler specific code in #ifdefs? For example, for gcc and for other compilers?
Code: Select all
localtime_r()Code: Select all
chSysLock(); localtime(); chSysUnlock();- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: The RTC driver topic
The problem is that some compilers don't support localtime() at all. This is why I wrote to support FAT time directly in the driver without dependencies, all conversions done inside directly from RTCTime to fattime.
rtcGetTimeFat() would be part of the driver interface, I don't really care about the other time formats like struct tm and Unix, that stuff brings in a lot of libraries including 64 bits integers.
Giovanni
rtcGetTimeFat() would be part of the driver interface, I don't really care about the other time formats like struct tm and Unix, that stuff brings in a lot of libraries including 64 bits integers.
Giovanni
- Giovanni
- Site Admin
- Posts: 14893
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 997 times
Re: The RTC driver topic
Probably it is better to move rtcGetTimeTm(), rtcSetTimeTm() back into the driver and make them available only if the compiler supports time.h using a switch defined in the low level driver: RTC_SUPPORTS_TM.
rtcGetTimeFat() also moved in the driver and would always be available regardless the time.h support.
Unix time format is not required, it can stay external, it can be converted from the tm structure anyway so there is no reason to support it in the core OS.
Giovanni
rtcGetTimeFat() also moved in the driver and would always be available regardless the time.h support.
Unix time format is not required, it can stay external, it can be converted from the tm structure anyway so there is no reason to support it in the core OS.
Giovanni
Re: The RTC driver topic
Giovanni, Barthess,
For the STM32F1..., Martin Thomas has some compact time functions including fattime converrsion. Some of them are derived from other sources as noted in his comments. For the F2 where the RTC stores datetime in calander format fat time conversion is trival.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32
Note the following though. In rtc.c, counter_to_struct() has a configurable epoc FIRSTYEAR for converting the F1.. counter to datetime format but struct_to_counter() has a hard coded offset. It is set to the year 2000 in the example
Can be changed to UNIX time
This really needs converting into a macro if it is to be compile time configurable.
I don't think any other time.h functionality should really be required.
saraben
For the STM32F1..., Martin Thomas has some compact time functions including fattime converrsion. Some of them are derived from other sources as noted in his comments. For the F2 where the RTC stores datetime in calander format fat time conversion is trival.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/arm_memcards/index.html#chanfat_stm32
Note the following though. In rtc.c, counter_to_struct() has a configurable epoc FIRSTYEAR for converting the F1.. counter to datetime format but struct_to_counter() has a hard coded offset. It is set to the year 2000 in the example
Code: Select all
result -= 730485UL;Can be changed to UNIX time
Code: Select all
result -= 719528UL;This really needs converting into a macro if it is to be compile time configurable.
I don't think any other time.h functionality should really be required.
saraben
Re: The RTC driver topic
rtcGetTimeFat() for hardware calendar moved inside driver and tested on F4x board (rev 4701).
saraben,
thanks for link, I will look close this evening.
saraben,
thanks for link, I will look close this evening.
Re: The RTC driver topic
Giovanni,
is licensing scheme allow to use this code in chibios?
http://code.google.com/p/sistemasembebi ... /rtc.c?r=9
is licensing scheme allow to use this code in chibios?
http://code.google.com/p/sistemasembebi ... /rtc.c?r=9