[RFC] Adding RTC API

[jdascenzio]

Hi,
I'm working on a RTC driver for stm32. Currently in Zephyr, RTC is used as a counter. In my project, I would like to use it at a real clock time to timestamp my data. I also integrated this driver in clock_[get/set]time. I'm open to all suggestions to improve it. In the future, I would like to integrate also alarm

[zephyrbot]

All checks are passing now.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[nordic-krch]

so RTC is used only for REALTIME. Could that be an issue in some cases? It means that those clock ids are using different source clock thus accuracy. I'm not sure what are the typical uses cases but can imagine that someone reads both at one point of time and next time in an hour. Monotonic will show different time elapsed than realtime.

[jdascenzio]

In my system I need to timestamp some data precisely. My system could run during a long time without time synchronization. The RTC have a lower clock drift than system clock.

[nordic-krch]

exactly, thus i wonder if it is possible to provide monotonic based on RTC device. Maybe logging uptime offset when settime is called?

[jdascenzio]

There is 2 problems to use RTC as monotonic:

• According to Posix: "the MONOTONIC clock is not affected by discontinuous jumps in the system time". (A workaround will be to save the offset on settime and use it to correct monotonic clock)
• The resolution for shorter time is better with system clock

[pabigot]

API 2020-07-07: Moved from triage to To-Do pending submission of draft proposals by @pabigot, @henrikbrixandersen, or others.

[llisauskas]

@jdascenzio is this PR going to recieve any updates? I'm planning to start work on something similiar, since my system requires this, but it does not make sense if this is going forward. I can contribute if it get's approved.

[jdascenzio]

@jdascenzio is this PR going to recieve any updates? I'm planning to start work on something similiar, since my system requires this, but it does not make sense if this is going forward. I can contribute if it get's approved.

For now, I have stopped to work on it. I used this driver which suits me for the moment. Maybe @pabigot or @henrikbrixandersen will make a draft to add some of these functionalities in driver counter....

[pabigot]

For now, I have stopped to work on it. I used this driver which suits me for the moment. Maybe @pabigot or @henrikbrixandersen will make a draft to add some of these functionalities in driver counter....

The architecture design I still support is that counters continue to provide an integer interface, and things like timeutil_timegm64 and gmtime are used to translate between civil and integer time representations to allow a counter to support civil time maintenance and alarms. There are also supporting capabilities necessary to:

1. register civil time against the local clock (without that being restricted to CONFIG_POSIX=y);
2. accommodate leap seconds and local time offset changes for people who require them; and
3. compensate for local clock skew.

I have draft support for the pieces of that that are important to me (1 and 3), but they didn't make the 2.4.0 deadline. I expect to get them posted around the time 2.5.0 development opens up in a few weeks.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[cederom]

Hello world :-) I also create set time by manual time shift on set add.. but this is not preserved across reboots. I have created a feature request for RTC framework here: #35333 :-)