Fix i2c busy / bus busy handling #35
Conversation
|
To be clear, this basically reverts 4d50753 |
|
Not true ! :) It keeps most of these changes, only it won't raise an error when |
|
I appreciate the clarification. I find Github diff mode quite hard to grok :/ |
|
No problem ! And I may still have overlooked something, so feel free to question my choices :) I can still say that previous try to use i2c always failed with the |
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
There was a problem hiding this comment.
Would like to hear from @dtwood before we merge.
Sorry, I completely missed this. Have just ordered myself some hardware, but since I can't get openOCD installed on this machine, it's going to take a while until I can test.
The code looks sensible to me (and definitely better to put the loop in the macro, rather than me leaving it out), so if this fixes things then happy to merge.
|
Great, thanks ! I can say that before your changes, i2c was really unstable, after your fix it does not work at all, and the combination of your fix and these changes makes it work flawlessly on my app. It is simple, so can't say it's a very robust test, but it is testing basic things... |
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 #34