[riot-notifications] [RIOT-OS/RIOT] drivers/rtc: Improved documentation (#11360)
notifications at github.com
Tue Apr 9 16:54:45 CEST 2019
> IMO, rtc should be completely abstracted and used as low-power timer that gets multiplexed as usual. calendar / clock alarms should then be implemented on top of that.
+1 for that. But the current RTC API is somewhat in between a high level and a low level API. E.g. I would not expect `struct tm` to have any meaning to a low level API. E.g. `struct tm` contains filelds like `tm_isdst` (is daylight saving time used?) or `tm_wday` (current day in the week). This stuff is better handled on top of a low level API.
Basically there are two types of low level time keepers, or am I wrong about that? The one category does only count seconds since some fixed point in time, and the other measure times in year/month/day/hour/minute/seconds - some with crazy stuff like hours in 12 h format + a bit for am/pm or using BCD encoded numbers. (I personally consider the second type as completely crazy and like asking for hardware bugs like [this one](https://lore.kernel.org/patchwork/patch/628142/), but actually most dedicated RTCs I'm aware of belong to this category.)
So how about defining two low level APIs, one using UTC in the 24h format (so with separate fields for year/month/day/hour/minute/second and hardware support for leap years), and the other begin in seconds since 1. 1. 1970 0:00:00 (UNIX/POSIX epoch time). On top of these APIs a high level RTC with multiple alarms, daylight saving time, maybe even leap seconds could be provided. This low level API would also not need to store the function pointer and argument for the callback. The upper layer RTC implementation would need to do house-keeping task (such as registering the next pending alarm) when the alarm rang anyway, so every call of the lower layer RTC part would call into the upper layer in any case.
(I assume that just having one low level API in UNIX time would not be accepted due to the extra overhead for dedicated real time clocks that do not use/provide UNIX time, right?)
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications