Fix support for 301 family

[danielgallagher0]

This crate has features for stm32f301xa, xb, xc, and xd devices, but ST does not have those in its product line. It does have 301x6 and 301x8 devices.

I propose adding features for 301x6 and 301x8 (and implementing those devices), and marking the other 301 features as deprecated. The 301xa/b/c/d support can then be removed at some point in the future.

[strom-und-spiele]

I'd just drop them (no one could have used them in the first place) and add x6 and x8.

[teskje]

See #115, would be good if one of you could review it.

I've decided to simply remove the sub-target features. It's a breaking change but as @strom-und-spiele suggested, it is very unlikely that anyone actually used those features, considering those models don't exist.

I also did not add new features for the x6 and x8 variants. Looks like they only differ in amount of flash, so I don't think we actually need to differentiate here. In any case, we can add them later if necessary.

[Sh3Rm4n]

I also did not add new features for the x6 and x8 variants. Looks like they only differ in amount of flash, so I don't think we actually need to differentiate here. In any case, we can add them later if necessary.

Speaking of features, those sub-variant differentiators for the devices always come in pairs of two: [xb, xc], [xd, xe], [x6, x8]. IIRC all those differ only in flash size.

If this is true, we could reduce the amount of features and combine these to `"xc/d", "xd/e", x6/8" features. Not sure about the feature naming though, as these are still somewhat user-facing and should be readable and comprehensible in the end.

[teskje]

I agree. Something like "stm32f303xc" is still understandable, while "stm32f303xbc" would be confusing.

I think if we do this change it would be the best to keep the current features and introduce "internal" ones which are actually used in the code. So in the Cargo.toml we'd have something like:

f303_bc = []

stm32f303xb = ["f303_bc"]
stm32f303xc = ["f303_bc"]

Something even more promising is figuring out what peripheral versions are used by the different MCUs, like the stm32l0xx-hal does (see stm32-rs/stm32l0xx-hal#82). Then we'd just have to provide in the Cargo.toml a mapping from MCU model features to peripheral version features and could implement our code based (mostly) on the peripheral version features. This should lead us to the minimum amount of #cfg(feature = ...) needed.

[Sh3Rm4n]

Something even more promising is figuring out what peripheral versions are used by the different MCUs, like the stm32l0xx-hal does (see stm32-rs/stm32l0xx-hal#82). Then we'd just have to provide in the Cargo.toml a mapping from MCU model features to

This approach looks interesting. I wonder, if we should create a tracking issue for these kinds of "small" internal code improvements 🤔