Simplify dma usage

[bjoernQ]

We used to move the driver and the buffers into the DMA transfer and have a way to get them back. That's to prevent the user from initiating another transfer or tamper with the buffers while the transfer is in progress.

However, this makes code using the API look quite clumsy and cumbersome.

We can avoid that by taking buffers and self as &mut (with appropriate life-times)

e.g.

before

        let transfer = spi.dma_transfer(send, receive).unwrap();
        (receive, send, spi) = transfer.wait().unwrap();

now

        let transfer = spi.dma_transfer(&mut send, &mut receive).unwrap();
        transfer.wait().unwrap();

Basically, the same thing we did to the passing of GPIOs into drivers (where we previously moved the GPIOs into the driver and had a free function to get them back - now we can pass &mut pins and "get them back" once the driver is dropped)

[MabezDev]

Sorry for these comments trickling in one by one :D, but should SpiDma also have a HalfDuplexReadWrite implementation? I guess it can't really because the buffer requirements for DMA usage are stronger ('static lifetime required) than the trait.

Maybe longer term we could think about relaxing this 'static requirement, and instead document that drivers should never be core::mem::forget'ed 🤔.

[bjoernQ]

Yeah, currently it can't but t.b.h. I wasn't sure if embedded-dma isn't too strict while doing the initial implementation but it's used a lot in other HALs so I just used it.

While requiring 'static is probably the safest thing to do, it's also somewhat inconvenient. Lifting that requirement is probably a good next step

[MabezDev]

While requiring 'static is probably the safest thing to do, it's also somewhat inconvenient. Lifting that requirement is probably a good next step

I'm glad we're on the same page, I'll make an issue to track/discuss that elsewhere. This PR LGTM now, just waiting on the next release. For my QSPI display use case, I can pump out an entire 356 * 400 * 2 frame buffer in around 7ms with DMA assistance 😎.

[MabezDev]

I opened #1245 with my thoughts.

[MabezDev]

I think because this affects the public API I guess we need a change log entry - after that, this looks good to go!

[bjoernQ]

I think because this affects the public API I guess we need a change log entry - after that, this looks good to go!

Oh yes - I just was a bit lazy since this shouldn't get into 0.16.0 or a patch release for that 😄 will add it before marking this as ready

[jessebraham]

Once CHANGELOG.md gets updated I think this LGTM. Once we've published our patch release tomorrow and @MabezDev has given his final stamp of approval, we can merge this I think.

Thanks for this contribution, this looks much nicer now!

[JurajSadel]

LGTM!

[jessebraham]

I think we're ready to move forward with this! If you don't mind making the last couple changes here, that'd be appreciated!

[MabezDev]

LGTM, thanks!