Reading an I2C device without a register ID?

[hexafraction]

Just got an answer; it's the first of the two options (multiple bytes read with ACKS until a final NACK)

[hexafraction]

I don't really understand your scenario but I can answer question 1.
1) You can do single register reads or you can do a block read where you specify the starting register address and the length as long as the I2C device supports it. Some don't support it (e.g. Sparkfun ZX distance sensor). I think all Modern Robotics I2C devices allow block read. See our version of the MR color sensor driver code. https://github.com/trc492/FtcSampleC...lorSensor.java

I'm asking at a much lower level regarding the read behavior. The CDIM can do one of two things:

* Send a start, device address (with RW bit set to zero), the register address, a repeated start, the device address (with RW bit set to one) and then keep clocking SDA with ACKs over and over again until it reads the whole block read.
* Send a start, device address (with RW bit set to zero), the register address, a repeated start, the device address (with RW bit set to one) and then clock SDA for only one byte. Then, repeat with the next register address.

Do you (or someone) know which of the two is the case for the CDIM with the FTC SDK doing a block read?

[mikets]

Hello all,
I'm trying to read an I2C device with a slightly peculiar documented behavior, in that on a read, after transmitting START and I2CADDR, it will begin immediately transmitting data (multiple bytes) to the I2C controller. Since the I2C code in the FTC SDK abstracts I2C behavior behind register IDs, I had a few questions:

1) Is a read performed by a bunch of single-register reads, or one long read that reads a bunch of bytes until a NACK (or end of read buffer) and then sends a STOP condition?
2) If the former, is there any workaround to make it perform the latter?
3) If the device ignores the register ID and begins driving the wire directly, would the correct resolution be to read register ID FF (so that the SDA line does not get pulled down by the CDIM), given that I'm OK with dropping the first byte?

Thanks!

I don't really understand your scenario but I can answer question 1.
1) You can do single register reads or you can do a block read where you specify the starting register address and the length as long as the I2C device supports it. Some don't support it (e.g. Sparkfun ZX distance sensor). I think all Modern Robotics I2C devices allow block read. See our version of the MR color sensor driver code. https://github.com/trc492/FtcSampleC...lorSensor.java

[hexafraction]

I got a response from ModernRobotics:

The CDIM conforms to standard EEPROM I2C protocol. The only way to operate the CDIM is by using a phone via the Android SDK or Core Device Discovery. The I2C protocols are handled within these applications so that you do not need worry about the low level I2C transactions. As of right now the SDK gives you the ability to read from I2C but not write to it. Using Core Device Discovery you can read and write to an I2C register.

If the sensor or third party device does not conform to the same I2C standard then that device is incompatible with our system.

Unfortunately this didn't help me, since there is no standard I2C EEPROM protocol beyond that which NXP specified in UM10204. I emailed them asking for further clarification but have not gotten an answer to this or to whether a multi-register read is a single multi-byte read or a bunch of single-byte reads. Is there someone with a CDIM, I2C sensor, and a logic analyzer, that can get a capture of an I2C read transaction and post it here?

[hexafraction]

Hello all,
I'm trying to read an I2C device with a slightly peculiar documented behavior, in that on a read, after transmitting START and I2CADDR, it will begin immediately transmitting data (multiple bytes) to the I2C controller. Since the I2C code in the FTC SDK abstracts I2C behavior behind register IDs, I had a few questions:

1) Is a read performed by a bunch of single-register reads, or one long read that reads a bunch of bytes until a NACK (or end of read buffer) and then sends a STOP condition?
2) If the former, is there any workaround to make it perform the latter?
3) If the device ignores the register ID and begins driving the wire directly, would the correct resolution be to read register ID FF (so that the SDA line does not get pulled down by the CDIM), given that I'm OK with dropping the first byte?

Thanks!