Arduino Due: problems with Wire library and SRF08 sonar #2586
Description
We are running into problems interfacing the SRF08 sonar (http://www.robot-electronics.co.uk/htm/srf08tech.shtml) with our new Arduino Due. We are using the exact same code as we used before for the Leonardo board. We only use the Wire library for the I2C communication.
First we excluded possible hardware failures, like the levelshifter that is inbetween the Due and the SRF08. We put the same board between the Leonardo and the sensor and the Leonardo still gave back the correct values. We also tried multiple Due boards.
To read out the values we first check the first register of the SRF08. This value implies the state of the sensor. A value of 255 implies that the sensor is ranging and therefore the distance values should not be read from the sensor yet. The problem is that we never get 255 back with the Due. With the Leonardo we do.
The next stage of the code reads out the distance values from the registers. The problem here is that sometimes this will fail, and we get bad values back. Once this happens, the Wire library keeps returning the same values on read, even when we physically disconnect the I2C wires from the Due. Only a reset fixes this (until it fails again).
We've identified the situation in which the read fails: The SRF08 is able to receive multiple echos from a single sonar ping. This enables the sonar to return multiple distance values (up to 17 values). As we're only interested in the first four values, we only request these four values (8 bytes). This never was a problem on the Arduino Leonardo. However, on the Arduino Due this read will fail if the SRF08 has more than four values available (this is the case if we increase the sonar gain, the SRF08 will receive more echos then).
We have also tried reading more values from the SRF08 (up to 15 values). In this case the reads work fine, but again until there are more values available than we requested.
Next we tried the fix of kevin-pololu on issue #1311 which stops the I2C connection from freezing (is it possible to merge this?). This does however stalls the Arduino for the timeout time, every time the connection would otherwise freeze. This will not be enough to solve our problem, since our appliction can net be stalled for that amount of time.