-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sys/ztimer: add ZTIMER_SEC, improve auto_init #16172
Conversation
wire up ZTIMER_SEC to the existing RTC backend, or RTT backend, or periph_timer backend (in this order of preference). Update sys/ztimer/auto_init.c Co-authored-by: Leandro Lanzieri <leandro.lanzieri@haw-hamburg.de>
The initial push has the fixups, that where just made to satisfy uncrustify, removed other than that it keeps the history. |
@jue89 and @vincent-d may want to review parts of this PR and where not auto added for review |
uncrustify is wrong about wrong about sys/include/ztimer.h#L297 and sys/include/ztimer.h#L309, changing to suggestion breaks the rule written in config (there is no multiplication in that lines) |
Is there any thing need to be done before this can merge? |
From my side, looking back at the original PR and comments, from #15715 (review), I still would like a test for
|
@fjmolinas: could you please be a bit more specific about the test you like to see? maybe you can provide a path. Marian already provided a test with "tests/ztimer_msg: Allow testing ZTIMER_SEC" Am i right that with your request for more documentation you mean more of the ztimer_periphry selection exposed to Doxygen? |
Allow testing does not mean the test is actually run, since it depends on a commented-out module the test is never run in the CI, I would rather have a distinct separate test application. Otherwise, this code is never compiled in. |
Exactly, your last commit addressed it perfectly. Thanks |
Although if @maribu think its OK as is, I won't block this, I think the PR is a very good shape, just don't like that the future is never compiled. |
I'll try find some time today to extend the existing ztimer tests to just iterate over all available clocks and test each. With a whitelist the How about this: If I manage to get this done today, @kfessel could rebase and extend the tests in the same fashion to also cover |
I just fished a really simple High level ztimer test that compiles all high level timers and uses them to unlock some mutexes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test looks good to me. IMO it is always good to (also) have simple tests. If a complex tests fails, one has to first understand the test before one can start debugging.
We can still independently of this PR extend the other ztimer tests to cover all clocks, to increase test coverage under more challenging situations.
squashed, the last two (new) commits make sure that no struct tm extra information (TZ and DST) leakes from riot to rtc or from rtc native to riot |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some typos, you can directly squash. (Ideally even before pushing.)
Note: If you split out the last two commits, they could go in right away.
i am unsure is it likely that this merges soon? |
typo sorry murdock |
MSEC and SEC are now usable on TIMER(0) without having USEC pm is configured by used hardware OLD configuration values are translated for backward compatibility prefer rtt for ZTIMER_SEC avoid doing partial ztimer setup if auto_init_ztimer is disabled before this patch some const pointers might have been definend to values that a user who disables auto_init for ztimer does not like.
provide more information about the selection procedure to Doxygen
contrary to the western civilised world struct tm requires us to count months from 0
{ .elem = 0 } initializes the complete struct to 0 {} is not ISO C conform
commit message typo |
@maribu have your changes been addressed? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK!, Thanks for pushing for this and sticking through @kfessel!
🎉 (Btw: I just noticed that I put a confused smiley to this PR. I hit the wrong icon, it should have been the thumbs up.) |
I adopted #15715 @maribu wired up some ZTIMER_SEC support supporting ztimer_periph_rtc and ztimer_periph_rtt
Contribution description
ZTIMER_SEC
support which is currently documented but missing.Testing procedure
by @maribu:
ZTIMER_SEC
. Note: Uncomment a line in the Makefile as documented thereZTIMER_SEC
-Run
make TEST_ZTIMER_CLOCK=ZTIMER_SEC -C tests/ztimer_underflow flash test
-This fails for me, which proves two things: a) wiring up the RTC worked, and b) there is a preexisting bug in master unrelated to the PR that needs fixing.
Issues/PRs references
#15715 the original
#15911 also goes for the power mangement association to the base clk
the PM naming improvement by #16160 is allready taken into account for the new defined base clock associated