Interfacing I2C device which does not take a command byte

[k-mouse]

Hi,
a first-time poster here looking for some help

I've been trying to interface my Raspberry Pi to a single-axis gyroscope with an I2C protocol. I am doing this using C++ with the i2c-dev.h-library.
I seem to be able to connect to it, but the received data does not make any sense. This is what I think is going on: the I2C interface on the ADC is very simple, it only requires to be addressed and a high read bit, then it will return 3-4 bytes of data depending on configuration. The problem here is that it does not take any command byte. The I2C functions in Linux on the other hand requires this command byte to be specified when using functions such as i2c_smbus_read_block_data() (see e.g. this overview).

If anybody could help me out here I would really appreciate it.

[joan]

Have you tried just reading from the device? Perhaps using i2cget from the command line.

A link to the specs or model number of the device may allow someone who has used the device to help.

[Hove]

i2c_smbus_read_byte() does not require a command byte - so it should give you what you need. I know nothing more about it - I just stumbled across it yesterday when I was looking into i2c_smbus_read_block_data() here: https://www.kernel.org/doc/Documentatio ... s-protocol

[k-mouse]

Joan: Using i2cget I can only get a single byte without providing a command address (or data-address at it seems to be called here).

The ADC with the I2C interface is an MCP3421 (datasheet, pdf).
The complete gyro PCB is a DC-SS010 (datasheet, pdf), with a sensor of the type XV-3500CB.

Hove: Good suggestion, the problem is that i2c_smbus_read_byte() only returns a single byte, while I need 3 to 4 bytes. Consecutive calls to this functions does not work (it would only read the first byte every time).

[k-mouse]

The problem seems to have been solved, although I do not know why it works.

I noticed that this Raspberry Pi ADC uses a similar ADC (specifically an MCP3424) and checking its datasheet I noticed it has almost the same I2C setup and communication.
I found a C example for this RPi ADC, and noticed that when they call i2c_smbus_read_i2c_block_data, they provide the configuration byte as the command byte. The configuration byte is a byte written to the ADC at first to set it up.
This seems to work, and the bytes are read correctly. Why this works on the other hand, I have no idea I tried to just set the command byte to some different random values, and it seems sometimes it works, sometimes not...

[k-mouse]

Sorry for the wall of posts here, but I now understand why it works.

As can be seen from this documentation, when you call i2c_smbus_read_block_data() it actually starts by providing a write signal before sending the command byte. Only after that it addresses the slave again and with a high read bit.
So the ADC interprets the command byte as a new configuration byte, and then it starts the read after being addressed a second time.
Not ideal, but it works. I kind of wish the i2c driver did what it says it does, just read, not write anything. Let me have control over that instead.