transfer all current feature gating to device specific features

[Crzyrndm]

MCU with missing PAC support is marked like
// feature = "stm32l471", // missing PAC support
when PAC support is resolved, feature gate can just be uncommented

This is pretty much the exact opposite style to #261 with no derived / internal features at all. There's enough inconsistencies that I can see this being beneficial, although some of the longer conditions are quite knarly

Missing PAC support is notably problematic, particularly for L451/L471, but several other locations as well. I've tried to leave these in place but commented where I find them

[korken89]

Hmm, I'm still at a loss on how to handle all these features...
I'm not sure what's a sensible approach to actually use. It does however seem like something per MCU is needed.

[Crzyrndm]

Hmm, I'm still at a loss on how to handle all these features... I'm not sure what's a sensible approach to actually use. It does however seem like something per MCU is needed.

I can't see a way to avoid per-MCU features. There's just too many "on this device / group of devices, needs to be done this way".

• Note that that most likely goes for the PAC too, there's already a few examples here where the PAC is missing definitions for devices in this PR. L471 was hit quite frequently by this (nevermind L4P/Q/R/S)

A quick skim of the other stm32 hal crates

• All have per-device features (although some take it further than others and include pin/memory variants)
• L0 takes it the furthest on device specific features, including the pin/memory variants
• F1 is very moderate. But that could just be the low number of devices they're supporting
• G0 is the closest to the current approach with per-device + G0x features
• G4 is pretty much this PR
• F3 is a bit of a mix, Not where I would have gone. it is the one that I noticed using build.rs for validation, which may or may not be a good idea
• F4 is probably the most extreme example of feature gating, but I'd also say that it's probably the cleanest design after seeing where this crate will need feature gates. Feature per-device (e.g. stm32f405) and the device selects any "not-core" peripherals / options.
  • The number of features and the level of derivation going on is a bit intimidating, but the in source decisions seem likely to be much clearer, and the complexity of the features is all in the quantity and largely in a single location

As a side note, the F3 use of the build script made me a bit curious. The build script can be used to enable crate local features, but no dependencies (since dependencies are built prior to the build script running, this does make a lot of sense...). Pretty sure this is not a good idea as it's just a bit outside the box

println!("cargo:rustc-cfg=feature=\"{}\"", name);

[Crzyrndm]

I do have a slightly different idea that, while it may not necessarily reduce the total complexity involved here, could help localise it (+ side benefits). Multiple crates

Each module has a relatively limited number of points where differences are encountered (and therefore features required if it was a crate). This crate acting as the umbrella connecting them all together needs only the device features (which then enable the relevant features in the sub-crates) and it would be quite easy to make the API of this crate look unchanged (i.e. modules or crates doesn't matter to a consumer). The number of features at a single crate is reduced to a manageable level (no combinatorial explosion -> testable).

Cargo workspaces work extremely well (including being able to use paths for development and versions for published releases so it can all be developed in a single repo without issue) so the downsides that I can see are mostly to do with publishing multiple crates rather than just a single crate and I have not a clue what is involved there.

The side benefit I mentioned would be that fracturing the crate will most likely generate some pretty good compile time improvements. For the project I have been working on (a moderate sized firmware), it takes about 100 seconds to build (minimal effort to optimise that). 40 of those seconds are spent waiting for the PAC and HAL crates to chug through as the last two crates, completely single threaded (note that this is just as pronounced when making changes to the HAL. One small change == 20 seconds compiling, and it hampers IDE responsiveness too)

Note: I refer to the module as being the crate boundaries here mostly because that's the smallest that could be sensible. groupings of several modules that reuse a common set of features would work as well
Note2: This split could be done progressively. Doesn't need to happen in a single PR. Would need to start with the core bits that are dependencies of the peripheral modules though (rcc, gpio, etc.)

[DrTobe]

I like this approach here more than the one shown in #261 because it leaves us with a cleaner Cargo.toml and that is where users will most probably have a look first. So I guess this approach here is less overwhelming from a user's perspective. I agree that "some of the longer conditions are quite knarly" as you have already noted but I would just live with that in those places where specific peripherals are enabled/disabled as a whole, e.g. enabling I2C4 or UART4.

And I would also like to remind that feature-gating devices also requires setting up alternate function pin mappings. I still think that the approach I have sketched in #253 could be a viable option there because it lists out the mappings per-device instead of per-peripheral. Currently, this is done in the peripheral implementations itself but I already find those hard to read, i.e. hard to verify.

[Crzyrndm]

I would agree that doing GPIO / AFx probably needs to be rethought and probably in a single location. The approach in gpio.rs does not make it easy to identify which device has which pins quickly. Second stage / #253 / changes here?

I would agree that this is the better starting point for per device features. It is more flexible inside the code (at the cost of verbosity) and can easily be extended later if reduced verbosity is required. #261 has probably served its purpose so I will close it

As far as overwhelming feature sets goes, Documenting it well in the readme, compile error message, and a large comment block / clear naming and separation in the cargo.toml (i.e. device features first, big comment block before internal features, internal features with clear naming convention e.g. prv_GPIOE, prv_GPIOF). Something like https://github.com/rust-lang/rfcs/blob/master/text/1977-public-private-dependencies.md would be really handy for this stuff

[Crzyrndm]

@korken89 rebased on master. What needs to happen to close this?

• Not sure if should add the full set of devices to CI
• A number of things that should be possible are blocked on PAC support (e.g. TIM3/UART4 for L45/L46)
• ??

[korken89]

Overall LGTM. Lets add all feature gates to the CI though, so we at least test that them all can build the HAL.

After that I'll merge this!

[Crzyrndm]

All of the standard L4 parts added. L4R/S (L4+) are not because support is pretty light and it makes examples quite difficult
Also added a group of comments in lib.rs with the major feature groups (L4x1, L4x2, ... / L41_L42, L43_L44, ...). Makes things a bit easier