stm32-rs / stm32l0xx-hal

A hardware abstraction layer (HAL) for the STM32L0 series microcontrollers written in Rust
BSD Zero Clause License
96 stars 60 forks source link

Missing alternate SPI pins for STM32L051? #213

Closed jcard0na closed 2 years ago

jcard0na commented 2 years ago

Observation

If I enable the mcu-STM32L051C8Tx feature, I get an error when assigning SPI pins GPIOB 3-5 to SCLK, MOSI and MISO.

99  |         .spi((sck, miso, mosi), MODE, 100_000.Hz(), &mut rcc);
    |          ^^^ the trait `PinSck<stm32l0xx_hal::pac::SPI1>` is not implemented for `stm32l0xx_hal::gpio::gpiob::PB3<Analog>`

These pins are not recognized as valid SPI pins for this subfamily. They are valid for x2 and x3, though

However, the datasheet for this target does show those pins has them as valid SPI pins.

image

The README explains that pin mappings are generated with cube-parse.

At the moment I can compile the code by defining the features individually.

# stm32l0xx-hal = { version = "0.9.0", features = ["mcu-STM32L051C8Tx"]}
# stm32l0x1 does not allow configuring SPI1 pins in GPIOB 3-5, contrary to what the datasheet says.
# so defining stm32l0x2 instead and pray for the best
stm32l0xx-hal = { version = "0.9.0", features = ["stm32l0x2", "lqfp48", "io-STM32L051", "eeprom-2048", "flash-64", "ram-8"] }

Questions

I still do not have hardware to test if this actually works, so this could very well be an error on the datasheet, or my interpretation of it. But if it is indeed a bug in this pin mapping, how could I submit a fix, given that pin mappings are automatically generated?

Thanks!

jcard0na commented 2 years ago

Oh, I just saw that this was fixed in the master branch (commit 645f1485c83a6f60f5b35b4f733aef76f205a78b)

So, yeah! (thanks @alexismarquet !)