gpio: Add basic functionality for GPIOs

[astapleton]

This adds the basic outline functionality for the GPIO module and will form the base for follow-up PRs (see #19, #20, #21) to round out the GPIO functionality.

The gpio module is largely based on/copied from the implementation in stm32h7xx-hal.

[richardeoin]

Nice tidy-up of the macro that was not saving any lines, although the docstrings are lost.

The docstrings looked ok in the docs, but not a big issue

[astapleton]

Good catch on the docstrings. I added them back. It's a little less neat, but I'm still not convinced that a macro is necessary.

[richardeoin]

Great that this GPIO implementation is applicable to H5 also! The H7 implementation this is based on was mostly contributed by @burrbull in stm32-rs/stm32h7xx-hal#347 and stm32-rs/stm32h7xx-hal#346

I haven't had time to do an in-depth review (limited time at the moment) but what I have seen is good :)

[astapleton]

Great that this GPIO implementation is applicable to H5 also! The H7 implementation this is based on was mostly contributed by @burrbull in stm32-rs/stm32h7xx-hal#347 and stm32-rs/stm32h7xx-hal#346

I haven't had time to do an in-depth review (limited time at the moment) but what I have seen is good :)

It seems that quite a few of the peripherals are very similar between the H7 and H5 (with some notable differences like a completely new DMA engine on the H5).

@burrbull, would you be interested in reviewing these GPIO PRs, if you have the time?

[burrbull]

@astapleton Good for initial stuff.

You could look at https://github.com/stm32-rs/stm32f4xx-hal/tree/master/src/gpio if you want to develop it further.

[astapleton]

@astapleton Good for initial stuff.

You could look at https://github.com/stm32-rs/stm32f4xx-hal/tree/master/src/gpio if you want to develop it further.

Wow, thanks for the quick response! Would you mind if I added you as reviewer to the other GPIO PRs I have? They include some of the other functionality you mentioned. I haven't included some of the smarter GPIO pin allocation stuff that the M4 library does because it seems like a big change that would have impacts on the downstream work that I've already done and want to push upstream before I start making additional changes like that.

[burrbull]

It seems that quite a few of the peripherals are very similar between the H7 and H5 (with some notable differences like a completely new DMA engine on the H5).

Was it really needed to create separate repo/crate from stm32h7xx-hal?
Maybe just add H5 support there?

[astapleton]

It seems that quite a few of the peripherals are very similar between the H7 and H5 (with some notable differences like a completely new DMA engine on the H5).

Was it really needed to create separate repo/crate from stm32h7xx-hal? Maybe just add H5 support there?

While a number of the peripherals are quite similar, some are also quite different: the H5 has a completely new DMA engine (GPDMA). In other ways the families are also quite different. The H5 family is all Cortex-M33 single core MCUs, vs the very complex multi-core H7s with mixed Cortex-M7/M4 cores. It introduces a slew of new security peripherals/modules, which can gate access to peripherals and other functionality, as well as support for some sort of Trusted Execution Environment implementation on a subset of the cores. It also uses a completely new system control block (SBS).

All that said, I think there's enough difference between the families to justify a different HAL to avoid adding significant complexity to the stm32h7 crate. I think if I was looking for a way of sharing code between the various ST modules, I think moving more of the peripheral control into separate crates would probably be my preferred solution. The SPI/I2C/GPIO/UART peripherals are quite similar across a number of families, not just the H7 and H5 families.