5 ms·
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
by 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 agoYou 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 agoThis 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 agoIndeed, 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…