-
Notifications
You must be signed in to change notification settings - Fork 61
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
I2C 'Wait until byte is transferred' loop #85
Comments
dbrgn
added a commit
to gfroerli/stm32l0xx-hal
that referenced
this issue
Mar 28, 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`.
@ijager can you test whether it works with the changes in #87 (https://github.com/gfroerli/stm32l0xx-hal/tree/i2c-correct-mappings)?
|
dbrgn
added a commit
to gfroerli/stm32l0xx-hal
that referenced
this issue
Apr 4, 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`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was reading the
i2c
code since I want to implement it for another chip. Then I encountered the following loop in thesend_byte
function:stm32l0xx-hal/src/i2c.rs
Line 188 in f3b3e82
This loop seems wrong as it only ever runs once. Guess it might still work in practice most of the time. I guess the idea was to wait for
txe
bit to clear like in two lines above?stm32l0xx-hal/src/i2c.rs
Line 183 in f3b3e82
The text was updated successfully, but these errors were encountered: