Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature gate devices #29

Open
16 tasks
MabezDev opened this issue Jan 7, 2019 · 17 comments
Open
16 tasks

Feature gate devices #29

MabezDev opened this issue Jan 7, 2019 · 17 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed

Comments

@MabezDev
Copy link
Member

MabezDev commented Jan 7, 2019

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

L4x6

  • stm32l496
  • stm32l4A6
  • stm32l476
  • stm32l486

L4x5

  • stm32l475

L4x3

  • stm32l433
  • stm32l443

L4x2

  • stm32l452
  • stm32l462
  • stm32l432
  • stm32l442
  • stm32l412
  • stm32l422

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.

@MabezDev MabezDev added help wanted Extra attention is needed good first issue Good for newcomers labels Jan 7, 2019
@twilco
Copy link

twilco commented Jan 25, 2019

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?

@MabezDev
Copy link
Member Author

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.

@twilco
Copy link

twilco commented Jan 26, 2019

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

@MabezDev
Copy link
Member Author

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

@mathk
Copy link
Contributor

mathk commented Mar 25, 2019

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

@ryan-summers
Copy link
Member

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:

image
image

@mehmetalianil
Copy link

I have an STM32L475, and would love to contribute.

@DrTobe
Copy link
Contributor

DrTobe commented Sep 11, 2020

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.

@korken89
Copy link
Collaborator

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!

@mehmetalianil
Copy link

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?

@robbym
Copy link

robbym commented Apr 14, 2021

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

@MathiasKoch
Copy link
Collaborator

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

@Crzyrndm
Copy link
Contributor

Crzyrndm commented Oct 14, 2021

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

@Crzyrndm
Copy link
Contributor

Crzyrndm commented Dec 11, 2021

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 (#Cargo should allow features/optional-dependencies to be private or public, private by default rust-lang/cargo#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? transfer all current feature gating to device specific features #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>)

@korken89
Copy link
Collaborator

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.

@benjcollins
Copy link

benjcollins commented Jul 10, 2023

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?

image

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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests