sys/ztimer: make use of periph_timer_query_freqs #20582
Open
+144
−14
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add an API to search for the frequency supported by a timer that is closest to the given target frequency. This is in fact non-trivial to get right, as pre-scaler registers can be 16 bit or even 32 bit in size, making a naive loop over all possible pre-scalers too expensive (computationally).
maribu
added
Type: new feature
maribu
requested review from
leandrolanzieri,
aabadie,
MichelRottleuthner,
kaspar030,
bergzand and
MrKevinWeiss
as code owners
github-actions
bot
added
Area: tests
maribu
force-pushed
the
ztimer_periph_timer_query_freqs
branch
from
e1ba4e2 to
a1a90c7
Compare
This makes use of the `periph_timer_query_freqs` feature: 1. It does choose the closest frequency supported before calling timer_init() in the ztimer_periph_timer backend. 2. It does make use of the actually chosen frequency when using `ztimer_convert_frac`. 3. It does `assert()` the frequency is within 5% of the specified when no frequency conversion is performed or `ztimer_convert_shift_up` is used.
maribu
force-pushed
the
ztimer_periph_timer_query_freqs
branch
from
a1a90c7 to
6d3abf6
Compare
maribu
force-pushed
the
ztimer_periph_timer_query_freqs
branch
from
6d3abf6 to
4933b9b
Compare
MrKevinWeiss
added
State: waiting for end of feature-freeze
Process: blocked by feature freeze
MrKevinWeiss
removed
the
Process: blocked by feature freeze
|
Freeze is over so if anyone wants to pick this up... |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This makes use of the
periph_timer_query_freqsfeature:ztimer_convert_frac.assert()the frequency is within 5% of the specified when no frequency conversion is performed orztimer_convert_shift_upis used.Motivation
We have a number of MCUs that can run from internal oscillators (without using external crystal for accuracy):
periph_timer, so not relevant here)If those MCUs are used without external crystal, the actual CPU frequency may be off from what the the board config aims for significantly due to large production variance and temperature and supply voltage dependence. As a result, all
periph_timerinstances driven by the same clock will also be off significantly, which can hinder accuracy in time keeping significantly.This adds the support to ztimer to react on the actual frequency information provided by
periph_timer_query_freqsand adjust the time keeping accordingly.Testing procedure
As of now, only the MSP430 (and the FE310) will measure the actual CPU frequency at runtime, and only the MSP430 timer will compensate frequencies exposed via
timer_query_freqs(). So only on MSP430 this can really be tested now, e.g. withtests/sys/ztimer_msg.In
masterthis test sadly fails because oftimer_set()not yet working correctly on small timeouts (and waiting one period longer than needed).With this PR the test passes and the messages at second 30 is indeed about thirty seconds after the start message received. (It would be off by 40 % without compensation.)
Issues/PRs references
timer_get_closest_freq()#20581Fixes #8251