RMT: Support wrapping everywhere #4049
Merged
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
wisp3rwind
force-pushed
the
rmt-wrap
branch
8 times, most recently
from
89a7387 to
c140d1a
Compare
6 tasks
wisp3rwind
force-pushed
the
rmt-wrap
branch
3 times, most recently
from
b8e2993 to
1b8ae7f
Compare
6 tasks
wisp3rwind
force-pushed
the
rmt-wrap
branch
3 times, most recently
from
2e3849e to
a381207
Compare
- simplification and preparation for also supporting threshold interrupts - the split into a generic async_interrupt_handler and chip_specific::handle_channel_interrupts didn't really simplify things: It avoided a little bit of repetition, at the cost of quite a bit of syntax, and was also a poor representation of the differences between chips (namely the fact that on esp32 and esp32s2, the ch_err interrupt does not differentiate rx/tx).
Preparatory work for async wrapping rx/tx. This has no effect for now, since the corresponding interrupts are never enabled.
While not essential to parse received data, which will typically look for an end marker to determine the actual end of the data, this still appears useful.
instead of copying some garbage to the result buffer
will be helpful for HIL tests
- handle wrapping rx (and varying device support) - fix/simplify logic around end markers - check that the rx buffer is not overwritten beyond the actually received data
which would happen for async tx
which would happen for async rx
this can happen if a large buffer is supplied to Channel::receive, which produces an InvalidDataLength Error and does not start rx, but still returns RmtRxFuture (which will yield an error when polled for the first time)
Contributor
Author
|
This should finally be ready to go; what do you think? |
This was referenced Oct 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝
cargo xtask fmt-packagescommand to ensure that all changed code is formatted correctly.CHANGELOG.mdin the proper section.Extra:
Pull Request Details 📖
This adds buffer wrapping support to blocking/async rx/tx methods (previously, only blocking tx did support this).
Some preparatory refactoring and a few (IMO) convenient API additions are included. There's only one small change to existing API, which is included in the migration guide.
(Using this should also greatly help with esp-rs/esp-hal-community#32, if someone (not me) creates a PR to use async wrapping tx.)
Testing
HIL tests (incl. new ones)
Closes: #2723
Closes: #1779