-
Notifications
You must be signed in to change notification settings - Fork 2.1k
kinetis: periph/timer use LPTMR for TIMER_0, PIT for TIMER_1, TIMER_2 #4065
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
Closed
Conversation
This file contains hidden or 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
9c29864
to
06b4b69
Compare
This was referenced Oct 23, 2015
06b4b69
to
0da0246
Compare
Rebased on top of latest #3990 |
0da0246
to
2b9a01d
Compare
46be693
to
2823eac
Compare
- Safer handling of targets when using XTIMER_MASK - Reduce number of redundant branches - Avoid possible timer underflow when subtracting XTIMER_OVERHEAD - Spin at the end if target time is close
…CKOFF If XTIMER_OVERHEAD is greater than either XTIMER_BACKOFF and/or XTIMER_ISR_BACKOFF then it will be possible schedule low level timers with a negative offset, which means the timer will delay until the next overflow.
64-bit version of div_u32_by_15625div512 also updated tests-div to use correct order for expected and actual values in unit tests (embUnit)
Set XTIMER_HZ in periph_conf.h to specify the xtimer hardware timer frequency. The xtimer system uses the hardware timer's own tick representation internally but a thin wrapper layer is added as a shim between xtimer core and the public xtimer API which is based around microseconds as the time unit. Initially supports only 1000000 Hz (and powers-of-two divisions of it) and 32768 Hz, but can easily be expanded by adding a new case for XTIMER_HZ inside xtimer.h
- drift is the total difference from the expected time - jitter is the difference only since the last printout
… timers, and the 2**32 usec barrier
2823eac
to
98e598a
Compare
Seems unlikely to get ready for this release. |
closed in favour of #5294 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area: timers
Area: timer subsystems
Platform: ARM
Platform: This PR/issue effects ARM-based platforms
State: waiting for other PR
State: The PR requires another PR to be merged first
Type: enhancement
The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
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.
Depends on #3990,
#4040, #4827, #4183This PR modifies the periph/timer interface to use the low-power timer (LPTMR) for TIMER_0 and use that timer for the xtimer system. The LPTMR module has the benefit that it does not stop when entering any low power modes, so it can be used as a reliable timer source for a power saving radio MAC layer.
TIMER_1 and TIMER_2 are using the PIT module, which only runs when the CPU is in RUN or WAIT mode, i.e. full power.
The LPTMR module resets when stopping, so in order to prevent the timer from going backwards when setting a new time we use the RTT module as a reference point for
lptmr_read()
. This avoids the convoluted (sometimes even ineffective) extra measures that were used in the old hwtimer implementation to avoid dropping ticks on the LPTMR module.This PR is somewhat controversial because it modifies the periph/timer driver to use three different hardware timers running at different frequencies.