drivers/periph_timer: add periph_timer_capture API #20519
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
This adds an API to use timers in capture mode. A brief look in a number of data sheets has revealed that even primitive timers such as ATmega or MSP430 timers allow using both capture and compare mode to be used in parallel. Most use the channel compare target register as capture register, when a channel is in capture mode. Some (e.g. ATmega) have a dedicated capture register that is not shared with compare channels. The API intents to reflect this by allowing capture channels to overlap with compare channels, or to have distinct numbers. The number of the first and the last capture channel for each timer can be queried by the API. A default (weak symbol) implementation can be used when all compare channels can be used as capture channels, which seems to be the case for most timer peripherals. An implementation is expected to rely on a board or MCU level configuration that maps channels to event sources (such as internal triggers or GPIO pins). A function to query which GPIO pin a specific channel on a given timer refers to is provided, which will return `GPIO_UNDEF` for internal triggers. Managing internal triggers are out of scope for a hardware abstracting peripheral API, as those can widely vary between MCUs. However, managing the capture channels linked to internal triggers will work with this API in the same way as capture channels linked to external triggers. The internal triggers will be particularly useful to implement a mechanism to synchronize timer peripherals, e.g. to convert timestamps captured on peripheral A to timestamps on timer peripheral B that is used in compare mode.
Add capture config when TIM2 or TIM5 and TIM2 are used as timers and add the feature to the effected boards.
maribu
requested review from
leandrolanzieri,
aabadie,
MichelRottleuthner,
MrKevinWeiss and
vincent-d
as code owners
github-actions
bot
added
Platform: ARM
maribu
added
the
CI: ready for build
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 adds an API to use timers in capture mode.
A brief look in a number of data sheets has revealed that even primitive timers such as ATmega or MSP430 timers allow using both capture and compare mode to be used in parallel. Most use the channel compare target register as capture register, when a channel is in capture mode. Some (e.g. ATmega) have a dedicated capture register that is not shared with compare channels.
The API intents to reflect this by allowing capture channels to overlap with compare channels, or to have distinct numbers. The number of the first and the last capture channel for each timer can be
queried by the API. A default (weak symbol) implementation can be used when all compare channels can be used as capture channels, which seems to be the case for most timer peripherals.
An implementation is expected to rely on a board or MCU level configuration that maps channels to event sources (such as internal triggers or GPIO pins). A function to query which GPIO pin a specific channel on a given timer refers to is provided, which will return
GPIO_UNDEFfor internal triggers. Managing internal triggers are out of scope for a hardware abstracting peripheral API, as those can widely vary between MCUs. However, managing the capture channels linked to internal triggers will work with this API in the same way as capture channels linked to external triggers.The internal triggers will be particularly useful to implement a mechanism to synchronize timer peripherals, e.g. to convert timestamps captured on peripheral A to timestamps on timer peripheral B that is used in compare mode.
Testing procedure
A test application was provided.
Note
The test app requires a jumper wire connecting a GPIO used as output to a GPIO used as trigger input and the corresponding configuration. See the test doc for details.
Click here for full test output
Issues/PRs references