Posted on August 10, 2012 at 22:01I was reading through the documentation on these and saw the ''block data update'' feature, obviously useful because it's two 8-bit registers and it might be possible for the data to update between reads and thus not read a coherent 16-bit value.
I am wondering if there's more specific data on this. As written, this seems potentially dangerous and could make it worse, potentially making a situation where it guarantees all values will be a glitched combination of LSB and MSB from two samples.
The problem is if somehow one sample is ever read without reading the other. It seems like the master and peripheral would then be forever out of sync. The master would read the MSB then the LSB, but due to a prior read of the LSB without a successful read to the MSB, the peripheral would see the MSB read and update the MSB/LSB there, then the master follows with a read of LSB and gets the wrong value.
It seems this situation would persist indefinitely, and would be almost impossible to detect with software, the result will just appear as ''noise'' near the boundary where the LSB rolls over and was supposed to accompany a change in the MSB.
It seems more logical that reading the lower register- the MSB in this endianess- would always get the newest sample and lock the LSB. But the spec doesn't say that, and the coder MUST know this, since otherwise you might code it to read the LSB first, which would always result in an incoherent sample.
Or is locking only effective during a single multi-byte I2C read across the registers, and a START condition resets the lock on the register? While this makes sense, I don't see any indication in the documentation that it works this way.
