Add stm32l4r9 support

[jspngh]

Hi, I'd like to use this HAL with an STM32L4+ device, more specifically the STM32L4R9.
An stm32l4r9 feature flag is available in the stm32l4 PAC, and has been added to this crate as well.

From my point of view, the main challenge is working around the differences in mapping peripheral requests to DMA channels.
While the "normal" STM32L4 devices use a CSEL register, the new STM32L4+ devices have a dedicated DMAMUX peripheral.
My idea is to create a unified interface, currently named set_request_line (taken from stm32h7xx_hal),
which takes as argument the peripheral for the channel (the PeripheralSelection enum, which lists all possibilities).
However, currently a lot of manual code is required to map this enum to the actual bits that should be used,
which has to be implemented differently for STM32L4 and STM32L4+ devices.
Maybe part of this could be generated from the SVD files.

I would like some feedback about this approach and suggestions for alternatives or ways to improve this.
The main implementation has been done in a new file (dmamux.rs) and uses a trait (DmaMux), this is all open to change.

Also relates to issue #209 and PR #239. Both of these have been open for a while and seem stale.

[jspngh]

After some discussion in the 'stm32-rs' matrix channel, I've decided to keep the manual approach in dmamux.rs, instead of trying to generate more in the PAC. That dmamux.rs module has been refactored a bit, and should be ready for review.
I've also enabled I2C, SPI, UART, and GPIO peripherals for the STM32L4R9.

Please let me know what you think, and where there is still some work.
If there are no remarks, I'll clean up that last "WIP" commit before merging.

[ByteNacked]

Wow, nice one, I'm recalling awful mess w/ DMA registers. Nice to see you fixed this.

[jspngh]

I see the repository has undergone some restructuring causing merge conflicts.
Is there interest in getting STM32L4R9 support merged in? Otherwise it's useless that I put in the effort to fix the conflicts.

[korken89]

With the new feature gates this PR makes a much better fit. If you fix it up again I'll merge it :)

[jspngh]

The PR has been rebased to the latest master.
I'm still not 100% satisfied with the interface for mapping DMA requests.

fn set_request_line(&mut self, request_line: DmaInput) -> Result<(), Error>

The error is only necessary because the try_into of the DmaInput can fail, but it feels like this could be checked at compile time in some way. So if you have suggestions for improving this, I'd like to hear them.

[gauteh]

Hi,

I have an STM32L4+ (STM32L4R5ZIY6), https://dev.blues.io/hardware/swan-datasheet/, which I would like to try and get Rust on. Is the difference to the R9 large or could I base differences off this one? Would you mind sharing which board you are using with the R9, if you are on a dev board.

Best regards, Gaute

[jspngh]

I don't think the difference should be very large if you get a PAC working for the R5/S5 devices, since they use the same reference manual (https://www.st.com/resource/en/reference_manual/dm00310109.pdf).
I'm not using a dev board unfortunately, but a custom PCB.
I see you've created a PR, so I assume you already got things running on your board?

[gauteh]

Thanks, yes. I managed to copy over the ADC peripheral and build the adc module as well, that will probably be useful for this MCU aswell. It runs (https://github.com/gauteh/swan-stm32l4r5-quickstart), but haven't tested any peripherals yet. Completely dependent on your work here though, thanks ! Hope it can be merged soon, it seems to work on the R5 at least.

[gauteh]

There seems to be a bunch of differences in the clock controls between L4 and L4+. A presentation with some differences.

It would probably be a lot of overlap between R5 and R9 regarding those, perhaps it would be better to work on one PR together?

[jspngh]

That's a good catch. The L4+ functionality does seem to be a superset or the regular L4, so I would think the current implementation also works for the newer devices, but will need to be extended to handle all new use-cases (like running up to 120MHz). Working together to improve L4+ support seems like a great idea.
In the meantime I'll rebase this PR to the newest master and ask if it can get merged, then new work can be its own PR.

[gauteh]

Good to know. Notably we are limited to 80Mhz for now.

Definitely, that is the best. There are still a few questions on getting r5 into the PAC distribution, does not look like it is going to be a problem, but it would delay a joint PR.

[jspngh]

Hi @korken89, could you let me know if this is suitable for merging? 🙏