Update I2C pin mappings based on STM32L0xx GPIO IP #87
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dbrgn
force-pushed
the
i2c-correct-mappings
branch
from
2f0109f to
4a8e60f
Compare
|
I have verified this PR against an STM32L071KBTx MCU and at least I2C1 seems to work properly. |
This was referenced Apr 3, 2020
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`.
dbrgn
force-pushed
the
i2c-correct-mappings
branch
from
4a8e60f to
a2dd816
Compare
dbrgn
commented
Apr 4, 2020
| feature = "io-STM32L031", | ||
| feature = "io-STM32L051", | ||
| feature = "io-STM32L071", | ||
| ))] |
There was a problem hiding this comment.
Multiple cfg attributes are additive (so both need to match), right?
I'm not sure whether stm32l0x2 is still required, but on the other hand I don't have much experience with DMA yet.
|
Looks good! Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The GPIO internal peripheral (IP) does not match the stm32l0x/stm32l0x2/stm32l0x3 grouping used in the PACs. 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:
We can use the
io-*Cargo features to differentiate between these mappings. This requires that the properio-*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 propermcu-*feature, for examplemcu-STM32L071KBTx.The pin mappings used in this changeset were taken out of the cube-parse output for the STM32L0 family. The output can be found here. To re-generate:
The source files in the STM32CubeMx database used to generate the mappings:
More information on the database format can be found in the cube-parse README.
The long-term solution should probably be a universal pin mapping file generated by cube-parse, but with the current APIs this would be a major refactoring. Therefore a manual fix must suffice for now.
Fixes #76, fixes #77, fixes #85.
CC @rnestler @DanSGiesbrecht @ijager