3 ms·

I2C has no concept of a discovery or identification packet. The host can write any data to any address, and you have to already know in advance what address and

I2C has no concept of a discovery or identification packet. The host can write any data to any address, and you have to already know in advance what address and data structure you need. The device can't tell you what its data format is. An I2C transaction begins with a client address, and the host waits for an acknowledge signal that a client has answered the message. That's it, that's the only standard part. From there, the host typically sends a register address and then some number of data bytes, or the client sends back some number of bytes. What those addresses and bytes mean are totally application-specific. There is no standard at all here. You could absolutely broadcast standard DDC commands to all addresses, but you have no way of knowing what actually happened. You might have turned off one monitor and set another to VGA mode. You might have just crashed some random device on the bus. You have no way to tell. All your host can possibly know is that there is a device at a given address, and it either did or did not send an acknowledge bit after a command. That's all the information available to you, and it is not enough to do what you suggest

myself248 2y ago
In recognition of this chaos, https://i2cdevices.org/ https://i2cdevices.org/ is putting together a pretty good list.
FredFS456 2y ago
That's not technically true - you can probe for I2C devices by only sending a START, an address, waiting for the client device to ACK (or not), and then sending a STOP. I don't think the linux kernel driver allows us to do this, but I've implemented this on some microcontrollers with lower-level control over the I2C hardware. It worked on all clients I tried it on.
- joezydeco 2y ago
  You can install i2c-tools and run i2cdetect from userspace. https://learn.adafruit.com/scanning-i2c-addresses/raspberry-pi https://learn.adafruit.com/scanning-i2c-addresses/raspberry-...
  - rasz 2y ago
    "Warning This program can confuse your I2C bus, cause data loss and worse!"
    - joezydeco 2y ago
      This is true. As stated elsewhere, sending START conditions to random I2C devices may confuse certain parts. It may also interrupt a driver that's already talking to a part on the bus. But in my lifetime working with I2C, I've never seen a part just go haywire because you scanned it this way.
- BobbyTables2 2y ago
  Indeed, I’ve also done the same. It’s frustrating how Linux doesn’t allow this. Part of me wonders if all devices actually handle a STOP before the first data byte correctly — without side effects…

myself248 2y ago

In recognition of this chaos, https://i2cdevices.org/ https://i2cdevices.org/ is putting together a pretty good list.

FredFS456 2y ago

That's not technically true - you can probe for I2C devices by only sending a START, an address, waiting for the client device to ACK (or not), and then sending a STOP. I don't think the linux kernel driver allows us to do this, but I've implemented this on some microcontrollers with lower-level control over the I2C hardware. It worked on all clients I tried it on.

joezydeco 2y ago
You can install i2c-tools and run i2cdetect from userspace. https://learn.adafruit.com/scanning-i2c-addresses/raspberry-pi https://learn.adafruit.com/scanning-i2c-addresses/raspberry-...
- rasz 2y ago
  "Warning This program can confuse your I2C bus, cause data loss and worse!"
  - joezydeco 2y ago
    This is true. As stated elsewhere, sending START conditions to random I2C devices may confuse certain parts. It may also interrupt a driver that's already talking to a part on the bus. But in my lifetime working with I2C, I've never seen a part just go haywire because you scanned it this way.
BobbyTables2 2y ago
Indeed, I’ve also done the same. It’s frustrating how Linux doesn’t allow this. Part of me wonders if all devices actually handle a STOP before the first data byte correctly — without side effects…