Clean up DMA code #260
Clean up DMA code #260
Conversation
`Transfer` is the primary concept in this module, so it should come first.
Those types need to be specified in multiple places (and I'm going to add one more shortly) and the repetition is getting tedious.
The new name better reflects that it refers to the channel.
So far, only memory-peripheral transfers are supported. I see no reason to require a mutable buffer for that.
I intend this to become the new style for DMA-based I/O. It's much more visible than the method on `Channel` and it follows the convention in other HALs. Also, the method on `Channel` allows mixing channels and peripherals without restrictions, and needs to be made crate-private anyway.
It's part of a `Result::Err`, so this is pretty important.
It's an internal type, so it won't do any user-facing harm. It's also highly useful for a fix that I'm working on.
Close #119
It is only relevant, if hardware triggers are enabled, so having it here is misleading.
|
Force-pushed to remove a few commits, make some other slight modifications, and to sneak in another minor commit. The peripheral-to-memory transfers I'm currently working on seem to be taking a slightly different direction than expected, and some of the changes made here turned out to be counterproductive. @david-sawatzke, I figured making you review these changes, then making you review the changes undoing them in the next PR, would be inconsiderate, so I chose to clean up this pull request instead. |
|
(Also not a blocker and would necessitate some api changes, but the limit of 1024 should probably be enforced) |
Thanks for the review! I agree, but I'm going to merge now and address this in #261, to save myself the rebase. |
This PR is a meandering journey through DMA, cleaning up what needs cleaning, fixing some things, but not adding any new features. The most significant change is that a panic on LCP845 was fixed.