Feature gate devices

Question

Feature gate devices

MabezDev opened this issue 6 years ago · comments

Scott Mabin commented 6 years ago

Devices that need to be feature gated (taken from stm):

L4x6

stm32l496
stm32l4A6
stm32l476
stm32l486

L4x5

stm32l475

L4x3

stm32l433
stm32l443

L4x2

L4x1

stm32l471
stm32l451
stm32l431

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.

Tyler Wilcock · Answer 1 · Fri Jan 25 2019 12:59:05 GMT+0800 (China Standard Time)

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?

Scott Mabin · Answer 2 · Sat Jan 26 2019 06:18:22 GMT+0800 (China Standard Time)

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.

Tyler Wilcock · Answer 3 · Sat Jan 26 2019 08:59:58 GMT+0800 (China Standard Time)

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

Scott Mabin · Answer 4 · Sat Jan 26 2019 09:29:21 GMT+0800 (China Standard Time)

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

Mathieu Suen · Answer 5 · Mon Mar 25 2019 21:05:32 GMT+0800 (China Standard Time)

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

Ryan Summers · Answer 6 · Sat Mar 07 2020 21:15:16 GMT+0800 (China Standard Time)

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:

Mehmet Ali Anil · Answer 7 · Thu Aug 20 2020 17:17:52 GMT+0800 (China Standard Time)

I have an STM32L475, and would love to contribute.

Tobbe · Answer 8 · Sat Sep 12 2020 01:57:26 GMT+0800 (China Standard Time)

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.

Emil Fresk · Answer 9 · Thu Dec 17 2020 23:16:38 GMT+0800 (China Standard Time)

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!

Mehmet Ali Anil · Answer 10 · Wed Jan 20 2021 06:39:24 GMT+0800 (China Standard Time)

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?

Robby Madruga · Answer 11 · Wed Apr 14 2021 17:32:07 GMT+0800 (China Standard Time)

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

Mathias Koch · Answer 12 · Wed Apr 14 2021 17:47:10 GMT+0800 (China Standard Time)

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

JC · Answer 13 · Thu Oct 14 2021 12:10:42 GMT+0800 (China Standard Time)

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

JC · Answer 14 · Sun Dec 12 2021 06:55:01 GMT+0800 (China Standard Time)

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>)

Emil Fresk · Answer 15 · Mon Dec 13 2021 17:09:16 GMT+0800 (China Standard Time)

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.

Ben Collins · Answer 16 · Mon Jul 10 2023 21:22:16 GMT+0800 (China Standard Time)

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.

rrwalton · Answer 17 · Fri Dec 29 2023 05:21:21 GMT+0800 (China Standard Time)

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