I2C not working anymore #34
Comments
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 21, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the busy available and then wait for the controller to be ready at intermediate step. Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 21, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the busy available and then wait for the controller to be ready at intermediate step. Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 21, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the bus available and then only wait for the controller to be ready at intermediate step (not the bus to be available as it will be busy). Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 21, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the bus available and then only wait for the controller to be ready at intermediate step (not the bus to be available as it will be busy). Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
|
@dtwood any thoughts on this one? |
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 23, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the bus available and then only wait for the controller to be ready at intermediate step (not the bus to be available as it will be busy). Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
dkm
added a commit
to dkm/tm4c-hal
that referenced
this issue
Jul 27, 2020
Restore previous logic where a transaction starts by waiting for the controler to be ready and the bus available and then only wait for the controller to be ready at intermediate step (not the bus to be available as it will be busy). Modify the i2c_busy_wait to implement this behavior. fix rust-embedded-community#34
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
After last changes in I2C, it seems the logic of the busy_wait macro is not correct.
I've been able to patch it locally and will push a clean proposal tomorrow (@thejpster asked me to file an issue).
Basically, checking for BusBusy everywhere is not correct as it will always be set between START and STOP, so during a transaction, we should not return an error (that's what I'm currently seeing).
Previous code was basically adapted from stm32f30x-hal and I see that the busy_wait macro has been changed (no more flag as parameter) and is not really busy_waiting on anything but the BUSY bit. The macro is now wrapped in
loop{}. Was is not better to have the busy wait inside the macro ? Maybe there's something I'm not seeing here.The original code was doing things like:
busbsyto be clearbusyto be clear....
I see that previous code was wrongly looking at all
mcsbits without waiting forbusyto be clear, but maybe the cleaning went too far ? At least with my patch that reverts back the logic above, my application is working correctly again.The text was updated successfully, but these errors were encountered: