ChibiOS Free Embedded RTOS

I propose to place

in os/hal/platforms/STM32F1xx/hal_lld.h and remove this lines from hal_lld_f105_f107.h, hal_lld_f103.h, hal_lld_f100.h files because this is common capabilities for F1x platform.

Second proposition:
Introduce functions RtcGetFatTime() to use in FatFS.

I agree with that, I also included some definitions about FAT date/time in rtc.h. In a small system it is probably more useful than Unix time or some invented format.

Giovanni

Thanks, guys, for the work on this. I look forward to trying out the RTC support soon.

Giovanni wrote:I agree with that, I also included some definitions about FAT date/time in rtc.h. In a small system it is probably more useful than Unix time or some invented format.

In my experience, which is mostly in the field of 802.15.4 wireless networked control and sensor monitoring, a linear time format makes time and date operation much cleaner since I'm usually doing arithmetic like computing the difference between points in time, comparing points in time, or adding a time duration to a point in time. These operations are single operations for linear time representations, but mean a lot of fancy carrying and knowledge of calendar formats including leap year and daylight savings time if you want to use the “calendar” YYYYMMDDhhmmss format. Certainly you can convert from Y-M-D h:m:s format to a linear scale (e.g., seconds since the epoch), but I would prefer to only do that for display purposes. It's an uphill battle, however, since most RTCs including NXP LPC1700 the STM32 RTCv2 at least are designed for the YMDhms format (and may unfortunately have seconds as the finest time unit!).

So, do whatever makes sense in ChibiOS to make it map well to hardware. Only, I hope it can provide subsecond precision when the hardware makes it possible. Will ChibiOS's RTC driver support the STM32 RTCv1 with a divider of less than 32768 so that millisecond precision is obtainable?

Hi colin
I am not against the linear time format, probably Giovanni too. But how to combine whole bunch of devices in single elegant interface that allow to access to:
- linear time
- calendar time
- fractional part of seconds if any?
Any ideas are welcome.

we can create some different functions:

- conversions between formats will be performed in HL driver
- subseconds by default will be used in "uint64_t rtcGetLinearTime(&RTCD)" if RTC cell supports it
That are my ideas.

It is an interesting problem. I'm not saying I have the answer... just wanted to explain how I have used RTC and time in my embedded applications. Certainly if you are mainly just letting the RTC keep time and use this for simple display to the user and maybe write some files to a FAT filesystem, you would like to use only Y-M-D h:m:s format and not worry about conversion.

On the other end of the spectrum, some applications may not set the RTC to “absolute real time” at all and might use it as a relative time counter just to support alarms to wake up from a low-power sleep mode where all the other clocks and peripherals in the MCU are stopped. These applications will generally do a lot of arithmetic and comparison operations with the RTC time, calculating how long to sleep based on what tasks need to be executed soonest, etc.

I don't mean to make you rethink the entire design: certainly conversion between linear time and calendar time is possible and actually necessary.

It brings to mind, however, the chainge effected moving from CHS (cylinder/head/sector) hard drive geometry to a linear block addressing (LBA) scheme.

barthess, I just read your next post as I was writing this and those are good ideas -- to allow the application to choose which representation to use by supplying two sets of get/set methods. That might be a nice solution, since only the functions actually used by the app would need to occupy code space, and no extra conversions would be necessary if the representation used by the application matches the hardware. Nice.

I'd prefer that the driver just do the driver and provide an opaque native RTC format, nothing else, conversions should be implemented in a separate library module.
- Native to DOS
- Native to linear
- Native to string
etc

The library module would have different code paths internally (compile time switches) to adapt to various native formats.

Let's keep issues separated or the RTC will become too complex. Soon we would be looking into automatic DST handling, timezones, leap seconds etc. Totally out of scope for a driver.

Giovanni

OK Giovanni, that seems reasonable.

Where is this ongoing work on the RTC driver being done? Is it in trunk?

What RTC improvements will make it into 2.4.x stable releases?

Giovanni, where is the place for such library in ChibiOS?