Wire.requestForm additional clocks generated
#176 aberto em 14 de jul. de 2017
Métricas do repositório
- Stars
- (952 stars)
- Métricas de merge de PR
- (Métricas PR pendentes)
Description
When I try to use Wire.requestfrom on the nRF52 there appear to be 1 bytes worth of additional clocks sent after the last byte I requested.
Has anyone else seen this effect.?
Note. Some I2C slave devices did not have a problem with this, but one particular device (a iqs263 touch screen controller) does not like the additional clocks
As far as I can tell, using Nordic's high level API for I2C does not have this problem
The operation of this I2C device is that you write the register number and the read 1 or more bytes from that register, depending on how many bytes are in that register
The device ID is 0x44 and I'm reading register 0x00 which is 1 byte long
Wire.beginTransmission(0x44); Wire.write(0x01);
Wire.endTransmission(false); Wire.requestFrom(0x44,1,false);
Note. The value returned by the read in these 2 images is different as the device is a touch sensor and is detecting the movement of my finger on the display, hence the value is different
However the value 0xFF should not be returned as it was not requested, and this eventually causes problems when I'm doing a multi-register read, as the slave device gets confused and generates a NAK which takes it off-line until its read the touch screen again (which takes several milliseconds)
This is what I see when using the Wire lib

And this is basically the same thing using the SDK - Note the extra clocks that send back 0xFF are not present and consequentially the rest of the transfer may be a bit different as the slave is getting messed up by the additional clocks
