search

David-OConnor / stm32-hal

This library provides access to STM32 peripherals in Rust.
MIT License
166 stars 44 forks source link

L4+ support (focussed on L4P5 / L4Q5) #62

Open FerdinandvHagen opened 1 year ago

FerdinandvHagen commented 1 year ago

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 commented 1 year ago

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

David-OConnor commented 1 year ago

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

David-OConnor commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.