You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When performing a read from i2c slaves with registers, the wire library appears to be failing on repeated starts. The bus gets stuck in a clock low state and the I2C state machine gets stuck in I2C_BUSY.
To work around the issue I have forced the processor to send a stop and start by changing:
Wire.beginTransmission(address);
Wire.write(subAddress);
Wire.endTransmission(false);
Wire.requestFrom(address, (uint8_t)1);
uint8_t data = wire.read();
to
Wire.beginTransmission(address);
Wire.write(subAddress);
Wire.endTransmission();
Wire.requestFrom(address, (uint8_t)1);
uint8_t data = wire.read();
This behaviour was found on a MPU6050A slave device. I have not tried other slaves but I believe this behaviour lies within the GD32 libraries. Has anyone experienced similar (or disimilar) behaviour?
The text was updated successfully, but these errors were encountered:
I think you forked my hoverboard sideboard repository ?
Yeah I couldn't get I2C to work on GD32 with MPU6050 or MPU6050A. I have very little experience with I2C unfortunately.
I can try your fix if it helps, and I have many of those boards with different IMUs.
@Candas1, I did fork your repo. I've been hacking around on top of it - very useful thank you.
The main problem with the workaround I'm using is it's only useful if you control the function call in your code, this precludes use of third party libraries without modification.
When performing a read from i2c slaves with registers, the wire library appears to be failing on repeated starts. The bus gets stuck in a clock low state and the I2C state machine gets stuck in I2C_BUSY.
To work around the issue I have forced the processor to send a stop and start by changing:
to
This behaviour was found on a MPU6050A slave device. I have not tried other slaves but I believe this behaviour lies within the GD32 libraries. Has anyone experienced similar (or disimilar) behaviour?
The text was updated successfully, but these errors were encountered: