Fix alternative function mapping for I2C on PA9/10 #76
Conversation
|
This modification doesn't appear to match the Alternate Function pin mapping of the STM32L011. Which exact MCU is this in reference to? |
|
Oh, that's really bad. This is for the STM32L071KB.
The STM32L011x3/4 is different indeed:
That means that there are major AF differences within the STM32L0X1 series 🤕 There are also differences for the USART AFs: The STM32L071 has USART4_TX on PA0/AF6, while the STM32L077 has USART2_RX on PA0/AF0 (and no USART4 on PA0/AF6). |
|
@dbrgn do you have any advice on how to restructure to address differences between MCU's? I'm currently developing for both STM32L071 and STM32L051, and am happy to help. |
|
I think the best long-term solution would be to extract AF mappings from the database shipped with CubeMX. The relevant discussion is probably at stm32-rs/stm32f0xx-hal#29. |
|
Sounds like a good path forward given the inconsistencies. That said, I'm open to other ideas. |
The GPIO internal peripheral (IP) does not match the stm32l0x/stm32l0x2/stm32l0x3 grouping. Instead, there are 4 different GPIO IPs in the STM32L0 family that define how the pin functions are mapped to the actual pins. This means that the current I2C mappings are broken for a lot of MCUs. For reference, these issues have already been opened because the mappings were broken: - stm32-rs#76 - stm32-rs#77 - stm32-rs#85 We can use the `io-*` Cargo features to differentiate between these mappings. This requires that the proper `io-*` feature is set when compiling (and is thus a breaking change). The easiest way to apply the feature without looking at the STM32CubeMX database XML files is to simply use the proper `mcu-*` feature, for example `mcu-STM32L071KBTx`.
The GPIO internal peripheral (IP) does not match the stm32l0x/stm32l0x2/stm32l0x3 grouping. Instead, there are 4 different GPIO IPs in the STM32L0 family that define how the pin functions are mapped to the actual pins. This means that the current I2C mappings are broken for a lot of MCUs. For reference, these issues have already been opened because the mappings were broken: - stm32-rs#76 - stm32-rs#77 - stm32-rs#85 We can use the `io-*` Cargo features to differentiate between these mappings. This requires that the proper `io-*` feature is set when compiling (and is thus a breaking change). The easiest way to apply the feature without looking at the STM32CubeMX database XML files is to simply use the proper `mcu-*` feature, for example `mcu-STM32L071KBTx`.
No description provided.