0

I have a raspberry pi connected with multiple i2c devices and want to be able to programmatically work out the type, manufacturer name, device name and/or description for each device on the i2c bus.

Is there any way to do this? Can it be done in python?

I can already get the ID numbers with python code the does essentially the same as i2cdetect, but it doesn't give any information that tells what each device is.

That means I have to manually dig through data sheets and then still have to disassemble the hardware and test with each individual device as the only one connected, to identify which device is at which ID, since some devices can be customized by altering their factory ID.

Putting it together in the first place was a huge job that I don't want to repeat, so I would rather have a way to identify each device programmatically. Does anyone know how or if this can be done? Does i2c protocol lend any support for that?

Could it be done indirectly, ie. is it possible to power down or otherwise temporarily mute or disable an i2c compatible HAT while the Raspberry Pi is running and then rescan the i2c bus and identify which ID no longer shows up?

zenmaster43
  • 21
  • 3

1 Answers1

0

No, the I2C bus is not designed for this.

The only way to do something like this is to have the knowledge of the possible addresses for each type of device stored somewhere, together with a way of detecting whether it's really that particular device. Some devices (such as the BMP/BME sensor family) have a ID register that can be used for this, but others don't have that. There are even devices (such as displays) that don't even support reading any data from them.

PMF
  • 14,535
  • 3
  • 23
  • 49
  • How would one go about detecting if an i2c device supports reading, without damaging or corrupting a device's registers? – zenmaster43 Jun 28 '22 at 08:19
  • @zenmaster43 That's actually what tools like `i2cdetect` do: They just read a byte from the device. This can (depending on the state of the device) have side effects, but that is generally ignored as it is expected that this operation is only performed while the device(s) are not in use. So you detect a device and afterwards you initialize it, setting it to a known state. – PMF Jun 28 '22 at 08:38
  • is there any online list of available i2c devices that includes make model and version information, so at least I could snail crawl the list and contact each manufacturer for device details. – zenmaster43 Nov 22 '22 at 00:47
  • @zenmaster43: Unfortunately, none that I know of. I would be interested in something like that as well. You can peek at software libraries to find the possible I2C addresses for specific devices, but that is quite a bit of work. – PMF Nov 22 '22 at 13:24
  • You're absolutely right. It is a huge amount of work, but I'm about half-way through compiling all of what I've found so far into a spreadsheet for visualization, but will eventually work it into a library, that will no-doubt need continual upkeep. It would be great to develop it into an industry-wide registry. – zenmaster43 Dec 07 '22 at 11:41
  • @zenmaster43 That sounds great. Since a library is always bound to a specific language (or platform), it would be great if that data was available in some computer-readable format, like an XML document. Then everyone could use it, even if they need it in a different language than your library is written in. – PMF Dec 07 '22 at 12:11
  • 1
    Good point. I'll keep that in mind going forward. Exporting the spreadsheet to XML should be quick enough. Then the library would only need to pull from the XML and the registry would need to update the XML for each new device registered. – zenmaster43 Dec 07 '22 at 12:18
  • @zenmaster43 Right. This even has the advantage that the XML can be updated without rebuilding (at least if the format didn't change). – PMF Dec 07 '22 at 12:57