search

stm32-rs / stm32l4xx-hal

A Hardware abstraction layer for the stm32l432xx series chips written in rust.
156 stars 103 forks source link

Feature gate devices #29

Open MabezDev opened 5 years ago

MabezDev commented 5 years ago

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

L4x6

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.

twilco commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

MabezDev commented 5 years ago

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

mathk commented 5 years ago

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

ryan-summers commented 4 years ago

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 commented 4 years ago

I have an STM32L475, and would love to contribute.

DrTobe commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

MathiasKoch commented 3 years ago

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

Crzyrndm commented 2 years ago

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 commented 2 years ago

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

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 commented 2 years ago

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 commented 1 year ago

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 commented 8 months ago

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