ADC Interrupt and DMA support

[datdenkikniet]

This PR adds support for sequences, interrupts and DMA requests to ADC1 by implementing from_adc for the dma::Transfer struct.

There is currently a problem with the L3 (also: L) bits in the SRQ1 register having the incorrect and inconsistent names across the parts. For now, I've feature gated this issue away. This problem is fixed in the latest source of the STM32L4 crate, but the fix has not been released yet.

[korken89]

Thanks for the PR!

Could you add an example to the the repo for easier testing?

[akloboucnik]

Could I have a question about usage of the new Transfer API for the ADC? If I understand correctly it takes ownership of the ADC peripheral and I'm unable to ever get it back - so if I for example want to reconfigure the ADC to different parameters, or get another sample afaik I'm unable to because it's always owned by the one transfer struct created with from_adc function.

I've noticed that for example in the F4 HAL this is solved by the start function accepting a closure - https://github.com/stm32-rs/stm32f4xx-hal/blob/master/src/dma/mod.rs#L1236 and example of usage here: https://github.com/stm32-rs/stm32f4xx-hal/blob/master/examples/adc_dma_rtic.rs#L83.

Maybe this is beyond a scope of this PR and I'm fine with that, I'm just asking about the usage and - I'm also willing to help if wanted, needed.

[datdenkikniet]

Not quite: you can get the peripheral back through the wait method of the DMA channel (it's a little hidden, but actually implemented for all transfers for a specific channel). The Transfer I added builds on top of the already-existing Transfer stuff, it's just a little difficult to find everything in the (relative) jungle of macros.

I'm not sure if having a closure makes a lot of sense in this scenario, especially considering the fact that the DMA configuration depends on the ADC's configuration, so making changes to that would require changes to the DMA configuration. Perhaps there is something I'm missing there, though.

For further DMA discussions I'd recommend you check out #230, since we start using embedded-dma there, and the idea is that that will be merged before this PR.

[datdenkikniet]

Have added a usage example now :)

[akloboucnik]

Not quite: you can get the peripheral back through the wait method of the DMA channel (it's a little hidden, but actually implemented for all transfers for a specific channel.

Ok, this makes sense, I was able to use it in my code now - the usage example helped a lot, thank you!

[korken89]

Hi the new DMA interface is merged.
Could you have a look at updating this PR please?

[datdenkikniet]

I have updated this PR to be able to use the new DMA API now.

I seem to have lost the usage example in the process, so I'll have to find/re-add that before this can be merged.

Found it!

I've also disabled circular DMA requests for now, as I'm unsure how to properly implement it. I assume it'll require a CircBuffer.

[datdenkikniet]

This PR is now ready for review.

[korken89]

This looks good to me!

[korken89]

Any objections to merging @MathiasKoch ?