Support other packaging options (LQFP48, etc.)

[japaric]

Currently the gpio module assumes that the target device has 100 pins but the devices in the STM32F30x (*) family also comes in 48, 64 and 144 pin packages (AFAIS)

Here's what I think we should do:

• We should add Cargo features for all the form factors. e.g. p48, p64, etc.

• We should conditionally remove / add pins depending on the form factor. In code it will probably look like this:

// Available on all form factors
pub struct PA0 { .. }

// Not available on the 48 pin form factor
#[cfg(any(p64, p100, p144)]
pub struct PC10 { .. }

It will actually look more complicated than that because we are using macros. Ideally the macro should let you input the #[cfg] attribute at call site. Maybe something like this:

gpio!(GPIOA, gpioa, gpioa, iopaen, ioparst, PAx, [
    PA0: (/* no attribute */ pa0, 0, Input<Floating>, AFRL),
    PA1: (#[cfg(any(p64, p100, p144)], pa1, 1, Input<Floating>, AFRL),
    // ..
]);

- Additionally the build script should reject selecting more than one of the form factor features.

Other modules may need to get the same treatment: for example USART3 may not be available in 48 pin packages, etc.

(\*) This includes families: STM32F301xx, STM32F302xx and STM32F303xx.

[burrbull]

CubeMX has db directory with xml-files describing all stm32 micros. I think those can be useful.

[austinglaser]

I like the idea of a configuration option. It fits in with the organizational hierarchy you seem to be using, where you have an <mcu>-hal crate, that's imported by a board crate -- the board crate can declare what package it's using.

It'll be important to configure unavailable pins so as to minimize current consumption. Generally, this seems to be done by configuring them as inputs with pullups or pulldowns.

The question cuts the other way too. Within the entire STM32 family, there are many reused peripheral blocks. As a single example, the GPIO peripherals on the STM32F4xx and STM32F7xx families are similar enough that ChibiOS uses identical low-level driver code for each.

This suggests that driver code could be reused beyond a single MCU-family crate. Ultimately, it might it make sense to make the <mcu>-hal crates aggregators more than anything else, which select and re-export a set of individual-device crates. I don't think this makes much difference to the actual issue at hand, however.