DMA (alternative to #209)

[9names]

Rebased #209 onto current trunk.
Updated to embedded-dma 0.2

Current plan is to drop everything except for SingleChannel, since I think that should end up being simpler and more flexible than the current approach.
To get bidirectional functionality from SingleChannel, will need to update peripherals to provide TX/RX endpoints so that the user can have 2 channels targeting the same peripheral for reading/writing.
For double-buffering I was thinking to pass the second DMA channel as an Option to the constructor, so the same interface is used regardless of single-shot/double buffering.

Will probably rename SingleChannel to Channel or Transfer or something to match the above changes.

EDIT:
After splitting it up, it looks like it already resembles the above somewhat so this might only require minor changes

Other goals:

• support transfer widths other than 32bit for peripherals
• address concerns with current interface raised in DMA on the way! #13 and Draft: DMA #209

[9names]

embedded-dma constrains DMA traits to WORD sizes, where WORD is u8/u16/u32/u64/i8/i16/i32/i64.
64bit sizes compile fine but do the wrong thing at runtime. There are now tests that show this is broken, not sure about the best way to proceed to fix that.

[9names]

Removed target tests from this branch since there's no practical way to keep CI happy with them in there. Will keep them in a separate repo for now.

[9names]

Turns out the solution to the CI problem was to exclude the on-target test project from the workspace.
There's still the rest of the problems that come from having a top-level .cargo/config, but those are at least potentially resolvable.

[jounathaen]

Another suggestion: Could you rename SingleBuffering to SingleBufferedTransfer (and Bidirectional accordingly)?
Found the other names a little clumsy when trying it out.

[9names]

Bidir is now working for SPI, at least with my trivial tests/examples.
One blocker down.

[jannic]

I still haven't had time to try this code. But as it reads nicely, contains test cases, and has been commented by multiple persons, I'd say we shouldn't wait for a more in-depth review before merging it. It has been waiting long enough.

[jounathaen]

I suggest resolving #528 before merging, as this would be a major API change afterwards.

[9names]

Alright, it's now updated to the API discussed in #528.
Looks okay to me :) but would appreciate another pair of eyes to review how the API looks @jounathaen

[jounathaen]

I think it is very nice now! Couldn't find anything more to complain about 😉

Thank you so much for your efforts!

[9names]

I did a test rebase and it looked sensible, so I'm going to trust that Github's "Squash and merge" is going to do the right thing 🤞