Menu
Just a quick question. On my i2c bus 0, I have two devices, 0x32 and 0x20.
When I use i2cdetect, only one of them shows up.
# ./i2cdetect -y 0
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- 32 -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --
The strange thing is, though, I can use i2cset and i2cget to send and receive messages to both of them just fine. I suppose this is not really a technical problem but just a curiosity -- why does 0x20 pretend that nobody's home?
Thanks!
449
i2cdetect is a userspace program to scan an I2C bus for devices. It outputs a table with the list of detected devices on the specified bus. i2cbus indicates the number or name of the I2C bus to be scanned, and should correspond to one of the busses listed by i2cdetect -l.
“UU” indicates that probing of this address was skipped because the address is currently in use by a driver. This is strong indication that the device is present, and highly likely that the driver is also in place. Device Address in hexadecimal indicates that the device has been detected.
Various I2C devices may behave differently when reading / writing bytes.
Some, for example, may expect write_then_read command, and won't acknowledge a standalone read command. Others may expect at least 16 bits of data to be read / written and otherwise the transaction fails.
i2cdetect can use different approaches for probing, such as read / write command, tuned by command line options. You may try -r or -q.
If that doesn't work, look at the command implementation and your device's datasheet, and make sure probing is possible.
64
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
