rcc: Add peripheral reset and control

[astapleton]

Adds helper functions for enabling, resetting and disabling peripherals via the RCC control interface.

Note: This also disables builds for the STM32H56/7x processors as the STM32H5 PAC crate does not provide the necessary definitions for the RCC at this time.

[joaomorenorf]

Hello, how can I help in this?
I have a special interest in the STM32H573.

[astapleton]

Hello, how can I help in this? I have a special interest in the STM32H573.

Hey @joaomorenorf! So I based this on top of the definitions I added to the stm32-rs repo to flesh out the peripheral definitions for the H503 (I mostly tried to include definitions for the H573 and H562/3 where they didn't significantly diverge from from the H503, but unfortunately the RCC was one case where it did).

You could make a PR into repo to add the definitions for the RCC for the STM32H573 (and STM32H562/3), as they share the same RCC definitions).

You can see what I've done with H503 here:

• H503 device: https://github.com/stm32-rs/stm32-rs/blob/master/devices/stm32h503.yaml#L31-L32
• I split the RCC register naming fixes into a common H5 and a H503 specific file:
  • https://github.com/stm32-rs/stm32-rs/blob/master/devices/common_patches/rcc/h5.yaml
  • https://github.com/stm32-rs/stm32-rs/blob/master/devices/common_patches/rcc/h503.yaml
• And did the same with the field definitions:
  • https://github.com/stm32-rs/stm32-rs/blob/master/peripherals/rcc/rcc_h5.yaml
  • https://github.com/stm32-rs/stm32-rs/blob/master/peripherals/rcc/rcc_h503.yaml

As I noted in a few of those files, the H573 is mostly a superset of the H503 in terms of functionality, so it should just be necessary to add the missing register definitions.

That all said... it took a while for my PRs to get merged into the stm32-rs mainline and published. While I think that is the better long term approach, and I would recommend you do so anyway, it would probably be possible to use the RCC definitions as provided by the SVD (ie. unpatched by stm32-rs) as a stopgap. It might be possible to adapt what I have here to use those definitions, or we could include a separate module that does the same thing for the H573 and H562/3 until they can be unified.

I can take a look at whether I can adapt what I have here easily, but I won't likely be able to get to it for the next week or so. Otherwise, if you wanted to take a stab at one or the other approach, that would be awesome, and I would be very happy to give you pointers, review etc.

[astapleton]

@joaomorenorf So I took another look at what was breaking the build, and realized that the main breakage was just that the clock source variants that let you easily select which clock to use for which peripheral are only defined for the H503. I reworked the macro in rec and was able to move those all into guards specific to the H503, and compilation now works for all variants!

There's one caveat: this means that to use one of these peripherals there would be the minor inconvenience of using the PAC directly to configure the clock source when a non-default clock is used for a peripheral, and when instantiating a peripheral driver such as I2C, you'd need to provide a dummy implementation of the ResetEnable trait (this will become more apparent as I merge these drivers in, but it's a pretty minor inconvenience, IMO) and everything should be otherwise quite useable.

I would still recommend making a PR into the stm32-rs repo (not sure when I'd get to it, tbh), and we can then incorporate the H573 peripherals into this module.

[astapleton]

@joaomorenorf On another note, I'll try to make sure that the code compiles for all variants (and keep them enabled in CI!), but I haven't tested anything on those variants, and there is a bunch of functionality that I haven't implemented (both for other MCUs in the family and in general). As an example in the RCC module, PLL3 for the H573 looks like it has a subset of the functionality of the other 2 PLLs, so we'd need to account for that before we can enable that PLL here.

As for how you could help further, testing the code on those MCUs would be super helpful, and your contributions to this repo for missing functionality would be very welcome too. I've still got a bunch of modules still to merge (e.g. serial, gpio, spi, i2c, icache), but there's a lot more that needs to be implemented, so there's plenty of scope to help.

[joaomorenorf]

Thank you, @astapleton, Now I'll focus on adding the registers definitions to stm32-rs.