Feature gate devices about stm32l4xx-hal HOT 17 OPEN

Are we limited by the fact that the stm32-rs library only specifies families for the l4 series whereas the f4 series has individual chips exposed?

from stm32l4xx-hal.

I'm pretty sure those are the chip families for the f4, as in the f4 hal crate there are more devices than there are listed in in the stm32-rs crate. I've updated the issue to include a list of the devices, which should make it easier to track what needs feature gating.

from stm32l4xx-hal.

Thanks for clarifying. I have an STM32L433 and would love to lend a hand with this issue.

from stm32l4xx-hal.

Awesome! If you've got any questions you can normally find me in #rust-embedded on irc.mozilla.org

from stm32l4xx-hal.

The L4x6 family is even split into those that have HSI16 and those that does not. How do you see that ?

from stm32l4xx-hal.

I'm in the process of bringing up a project using the STM32L452 and I'm starting to see the need here (e.g. SPI2 is not exposed via the HAL, but the device has SPI1, SPI2, and SPI3). Since I'll likely need to implement this for my project, I'd be happy to contribute it back to this repository.

Of interest is Section 1.5 of DM00151940, which lists Product-specific features for the STM32L4 family:

from stm32l4xx-hal.

I have an STM32L475, and would love to contribute.

from stm32l4xx-hal.

As far as I have understood, there are no chip/device-specific feature gates implemented currently, since I do not see any appropriate features (e.g. stm32l431) in Cargo.toml, is that correct?

If so, what is the current plan to progress here? Feature-gating a whole device with all peripherals seems like a huge amount of work to me. Maybe, this is the reason why this has not yet been done? Would it be feasible to keep the device-families as features (each feature activating the minimum subset) but additionally introduce chip-specific features which depend on the device-family-features? With that approach, chip-specific peripherals could be added without breaking anything because the current minimum subset would be kept and automatically be activated when enabling one of the chip-specific features.

from stm32l4xx-hal.

Hi, this is correct.
I am not sure on how to proceed here, but we do need to feature gate on each MCU.
If you have an idea I'm very open to input!

from stm32l4xx-hal.

If you fancy feature gating a device, you will need to go through reference manual for the chip family and feature gate the relevant peripherals. These are normally found in footnote e.g *not present on the stm32l4blahblah etc.

@MabezDev Footnotes in the Reference manual, or the tail of the source code? I would like to use feature gating to get accustomed to embedded-rust. Where shall I start?

from stm32l4xx-hal.

Will this HAL crate support the STM32L4+ series? Like STM32L4R9VG?

from stm32l4xx-hal.

@robbym I don't see why not, but i guess it boils down to someone wanting to contribute the required PR. 👍

from stm32l4xx-hal.

This is currently blocking me (see the ADC issue) leading to maintaining a fork for my current project. I don't want to continue this long term so want to at least make a start on this.

Is there any opinion on whether feature groups should continue to make source side feature checks less verbose? Potentially named as something obviously for internal use since many features are common to a large set of devices and AFAIK Rust doesn't have a good way to group features inside the source.
Example

internal_stm32l4x6_line = []
...
internal_stm32l47x_variant = []
...
stm32l476 = [ "internal_stm32l47x_variant", "internal_stm32l4x6_line" ]

I'm on the fence because while I like the idea, the STML4 HAL lists them explicitly and so cross verification would be somewhat easier

from stm32l4xx-hal.

With the merge of #266, advancing this should be a bit easier. My focus is likely to be geared toward the L476 and L496 as I have hardware which would benefit, but other bits and pieces are likely (e.g. #264 )

A few comments

• #[cfg] and features are to me a relatively irritating part of Rust in that many bits of it feel incomplete (e.g. no private features (#rust-lang/cargo/issues/7769), no #if ... #else ...) which leads to a lack of clarity by requiring the top level features to be used everywhere. I'm guessing macros could help here (based on cfg_if crate) but its really not an area of Rust that I know enough about so that's mostly speculation. Having a way of referring to L4x2 that didn't require listing the same 6 devices every time would be quite handy
• missing / incorrect PAC definitions definitely cause a few hiccups. I feel like this could benefit from a tracking issue,i.e. a list of known PAC issues with link, notes on any workaround (I've seem the wrong bit used a few times so it "mostly" works), and really just a place to see anything that is no longer blocked
• Finally, is there a reason to keep the separation of the USB_OTG / USBd feature? #266 didn't remove it or make it derived because I wasn't sure if there was more to it than just needing more specific feature gates

PS - the other thing that makes this difficult
There were several times where I got the conditional wrong and everything still compiled fine. Thinking that potentially one of the examples/tests should be a compile test that just pulls in as many peripherals as it should be able to (one function/module per device). Being able to confidently say that I didn't make a typo and e.g. remove the ADC from the L452 would be kinda nice (more likely issue: can no longer configure <insert peripheral> with <pin x>)

from stm32l4xx-hal.

For now, I think we are stuck in cfg-hell as you say. Sadly I have no good idea on how to generalize this better. :(

Having a way of referring to L4x2 that didn't require listing the same 6 devices every time would be quite handy

This would be great for not making copy-paste mistakes, but I don't think this exists today.

from stm32l4xx-hal.

Hi, I have a stm32l496 and seem to be missing PWM implementations for a number of the timers would feature gating this device allow me to use those features and if so how would I go about feature gating this chip?

In the data sheet it seems TIM5 and others should support being used as a PWM however in src/pwm.rs these implementations are not present.

from stm32l4xx-hal.

I have an stm32l475. Would definitely contribute if still needed.

from stm32l4xx-hal.