Skip to content
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

Merged
merged 11 commits into from
Apr 2, 2021

Conversation

kfessel
Copy link
Contributor

@kfessel kfessel commented Mar 9, 2021

I adopted #15715 @maribu wired up some ZTIMER_SEC support supporting ztimer_periph_rtc and ztimer_periph_rtt

Contribution description

  • add ZTIMER_SEC support which is currently documented but missing.
  • restructure the auto init. for readability an flexibility.
  • avoid the use of RTT for MSEC if its Frequency less than 1kHz.
  • puts the power mangement association to the base clk (basic timer / rtt / rtc)

Testing procedure

by @maribu:

  • tests/ztimer_msg has been updated to allow testing ZTIMER_SEC. Note: Uncomment a line in the Makefile as documented there
  • tests/ztimer_underflow has been updated to allow testing ZTIMER_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

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>
@kfessel
Copy link
Contributor Author

kfessel commented Mar 9, 2021

The initial push has the fixups, that where just made to satisfy uncrustify, removed other than that it keeps the history.

@kfessel
Copy link
Contributor Author

kfessel commented Mar 9, 2021

@jue89 and @vincent-d may want to review parts of this PR and where not auto added for review

@kfessel kfessel changed the title sys/ztimer: add ZTIMER_SEC sys/ztimer: add ZTIMER_SEC improve auto_init Mar 9, 2021
@kfessel
Copy link
Contributor Author

kfessel commented Mar 9, 2021

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)

@kfessel kfessel changed the title sys/ztimer: add ZTIMER_SEC improve auto_init sys/ztimer: add ZTIMER_SEC, improve auto_init Mar 9, 2021
@jeandudey jeandudey added Area: timers Area: timer subsystems Type: new feature The issue requests / The PR implemements a new feature for RIOT CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Mar 10, 2021
@kfessel
Copy link
Contributor Author

kfessel commented Mar 29, 2021

Is there any thing need to be done before this can merge?

@fjmolinas
Copy link
Contributor

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 ZTIMER_SEC.

  • it would be nice if the choice of initialization and backend was documented in another way as only with ifdefs, since they are really hard to read.
  • can we add distinctive tests for the different timers Since the application is the same mostly, I think an approach as the one used for the network driver compile test can be used

@kfessel
Copy link
Contributor Author

kfessel commented Mar 29, 2021

@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"
and "tests/ztimer_underflow: 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?

@fjmolinas
Copy link
Contributor

Marian already provided a test with "tests/ztimer_msg: Allow testing ZTIMER_SEC"
and "tests/ztimer_underflow: allow testing ZTIMER_SEC"

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.

@fjmolinas
Copy link
Contributor

Am i right that with your request for more documentation you mean more of the ztimer_periphry selection exposed to Doxygen?

Exactly, your last commit addressed it perfectly. Thanks

@fjmolinas
Copy link
Contributor

Marian already provided a test with "tests/ztimer_msg: Allow testing ZTIMER_SEC"
and "tests/ztimer_underflow: allow testing ZTIMER_SEC"

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.

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.

@maribu
Copy link
Member

maribu commented Mar 30, 2021

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 periph_rtt backend for ZTIMER_MSEC can be selected, for the others periph_timer is just used for both ZTIMER_USEC and ZTIMER_MSEC. (Using FEATURES_OPTIONAL += periph_rtt doesn't work, as an RTT needs to run at least with 1 kHz to be usable.)

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 ZTIMER_SEC. And I give my best that we don't need to worry about the other case :-)

@kfessel
Copy link
Contributor Author

kfessel commented Mar 30, 2021

I just fished a really simple High level ztimer test that compiles all high level timers and uses them to unlock some mutexes.
For testing rtt and rtc the respective module has to used.

Copy link
Member

@maribu maribu left a 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.

tests/ztimer_xsec/main.c Outdated Show resolved Hide resolved
tests/ztimer_xsec/main.c Outdated Show resolved Hide resolved
tests/ztimer_xsec/main.c Outdated Show resolved Hide resolved
tests/ztimer_xsec/main.c Outdated Show resolved Hide resolved
@kfessel
Copy link
Contributor Author

kfessel commented Apr 1, 2021

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

Copy link
Member

@maribu maribu left a 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.

cpu/native/periph/rtc.c Outdated Show resolved Hide resolved
cpu/native/periph/rtc.c Outdated Show resolved Hide resolved
cpu/native/periph/rtc.c Outdated Show resolved Hide resolved
@kfessel
Copy link
Contributor Author

kfessel commented Apr 1, 2021

i am unsure is it likely that this merges soon?
if not i would split out the rtc fixes

@fjmolinas fjmolinas added CI: run tests If set, CI server will run tests on hardware for the labeled PR CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR and removed CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR labels Apr 1, 2021
@kfessel
Copy link
Contributor Author

kfessel commented Apr 1, 2021

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
@kfessel
Copy link
Contributor Author

kfessel commented Apr 1, 2021

commit message typo

@fjmolinas
Copy link
Contributor

@maribu have your changes been addressed?

Copy link
Contributor

@fjmolinas fjmolinas left a 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!

@fjmolinas fjmolinas merged commit 9d1d2f9 into RIOT-OS:master Apr 2, 2021
@maribu
Copy link
Member

maribu commented Apr 2, 2021

🎉 (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.)

@kfessel
Copy link
Contributor Author

kfessel commented Apr 2, 2021

thanks 🎉

next stop #16160 and #16126

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: timers Area: timer subsystems CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR CI: run tests If set, CI server will run tests on hardware for the labeled PR Type: new feature The issue requests / The PR implemements a new feature for RIOT
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants