[RFC] Adding RTC API #23526
[RFC] Adding RTC API #23526
Conversation
jdascenzio
requested review from
carlescufi,
erwango,
galak,
MaureenHelm,
nashif and
pfalcon
as code owners
|
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. |
jdascenzio
force-pushed
the
rtc_driver
branch
3 times, most recently
from
b35cf6e to
fe2f35c
Compare
lib/posix/clock.c
Outdated
| @@ -26,6 +40,9 @@ int clock_gettime(clockid_t clock_id, struct timespec *ts) | |||
| { | |||
| u64_t elapsed_msecs; | |||
| struct timespec base; | |||
| #ifdef CONFIG_RTC | |||
| struct device *dev_rtc; | |||
| #endif | |||
|
|
|||
| switch (clock_id) { | |||
| case CLOCK_MONOTONIC: | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
exactly, thus i wonder if it is possible to provide monotonic based on RTC device. Maybe logging uptime offset when settime is called?
There was a problem hiding this comment.
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
jdascenzio
force-pushed
the
rtc_driver
branch
5 times, most recently
from
9150c9a to
ac9af10
Compare
github-actions
bot
added
has-conflicts
|
API 2020-07-07: Moved from triage to To-Do pending submission of draft proposals by @pabigot, @henrikbrixandersen, or others. |
|
@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.... |
The architecture design I still support is that counters continue to provide an integer interface, and things like
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. |
|
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. |
|
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 :-) |
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