L4+ support (focussed on L4P5 / L4Q5)

[FerdinandvHagen]

Currently draft - not tested but compiles on local stm32-rs version.

@David-OConnor appreciate any comments/reviews if stuff should be done differently.

On the Octo / Quad SPI: Would it make sense to have a separate module for Octo - compared to the Quad SPI.
There are a lot of functionality that seems to be missing on Quad SPI that is available on Octo SPI.

[David-OConnor]

Yea, send it. When I originally wrote this, the PAC for these wasn't out. Happy to merge once it works.

[David-OConnor]

Yea, send it. When I originally wrote this, the PAC for these wasn't out. Happy to merge once it works.

[David-OConnor]

Re octo/quad - yes, probably. I put it in the way it is as a stopgap, since MCUs have one or the other, and just wanted the octo ones to work with basic functionality. Def needs work re Octo

[FerdinandvHagen]

Hey @David-OConnor,

after some time away from embedded stuff I have picked up again working with embedded and the library.
The biggest issue with adding L4+ support at the moment however is that the underlying PAC is only available in the nightlies. Those nightlies however have the breaking changes I mentioned in #61.

My question is now how and if at all I should put time into this pull request for my HAL changes for L4+.

In my opinion merging changes for the L4+ only makes sense if at the same time the library gets based off a newer version of stm32-rs (aka nightlies) - as I'm not even sure it is even possible without doing so because L4+ is in the L4 crate and I think it's not possible to have two similar crates with different versions?.

Overall, I think the upcoming changes are very useful to implement as they shorten the code significantly (mainly due to being able to index arrays instead of those enums, etc.).

What are your plans around this? Have you already started incorporating changes from the nightlies?

[David-OConnor]

I think the answer is for stm32-rs to do a release of the l4 crate.

Because this HAL is intended to be used as a crate, it can't use dependencies that aren't on crates.io. (Not allowed by Cargo). It couldn't hurt to keep code ready for the new release, but I haven't done it. Overall, I think adding support for these MCUs is in scope and a good idea, but need to wait until the PACs are released in the l4 crate.

I'll ping the STM32-RS guys.