Clean up DMA module #262
Merged
Clean up DMA module #262
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
I plan to move the `start_transfer` method to `Transfer`, and in the future we will need to add more methods there, to control and query the ongoing transfer. Those methods will probably need most of these registers, so I figured why not just make all of them available.
I'm going to add more methods that need to access channel registers there anyway, and the start method seems to fit there better. Plus, all the compiler fence stuff is now concentrated in `Channel`.
Use a custom abstraction instead. cc #211
This makes using the DMA peripheral more convenient and opens the door for further simplications, at the cost of requiring more memory when the DMA peripheral isn't used (actually I believe that as of this commit, the compiler can optimize the static out, if DMA is not used; I'm working on further changes that would make this impossible). I think the added memory use if far from ideal, but right now I'd like to focus on a simpler and more flexible API. We can restore efficiency later, if desired, by being a bit more clever about using the static and allowing the compiler to optimize it.
It's an internal implementation detail now.
Since the descriptor table is no longer supplied by the user, a separate `split` step is no longer necessary. Please see the description of one of the previous commit for some notes on the consequences this change has on efficiency.
This removes the need for carrying a reference in every enabled channel, thereby removing the lifetime from channels and transfers, while offering the same guarantees. This makes the API much more convenient in non-trivial use cases. In addition, it allows for disabling the peripheral after a channel has been disabled, which has not been possible with the old API.
This follows the example from other modules, limits the wildcard re-export to that one module, and makes the `channels` module much lighter.
I believe the new name is much nicer and better reflects the difference between `Channel` and the trait. It also follows the example set by the peripheral APIs, so the consistency is an added bonus.
This was referenced Jul 28, 2020
david-sawatzke
approved these changes
Jul 29, 2020
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.
This PR contains multiple orthogonal clean-ups, the most significant of which removes the lifetime from
ChannelandTransfer, making the API much more convenient to use in non-trivial use cases.