elixir-circuits/circuits_i2c

`Circuits.I2C.detect_devices` detects lots of devices on rpi4 with v1.2.x

pojiro opened this issue · 6 comments

pojiro commented

I don't know if this behavior is correct, but I report this because the result of the behavior changed.
( I read the CHANGELOG.md of v1.2.x, this may be an expected change. )

With v1.1.0 on :nerves_system_rpi4, "1.22.0"

iex(1)> Circuits.I2C.detect_devices
Devices on I2C bus "i2c-1":

Devices on I2C bus "i2c-20":

Devices on I2C bus "i2c-21":

0 devices detected on 3 I2C buses

With v1.2.2 on :nerves_system_rpi4, "1.22.0"

iex(1)> Circuits.I2C.detect_devices 
Devices on I2C bus "i2c-1":

Devices on I2C bus "i2c-20":
 * 3  (0x3)
 * 4  (0x4)
 * 5  (0x5)
 * 6  (0x6)
 * 7  (0x7)
 * 8  (0x8)
 * 9  (0x9)
 * 10  (0xA)
 * 11  (0xB)
 * 12  (0xC)
 * 13  (0xD)
 * 14  (0xE)
 * 15  (0xF)
 * 16  (0x10)
 * 17  (0x11)
 * 18  (0x12)
 * 19  (0x13)
 * 20  (0x14)
 * 21  (0x15)
 * 22  (0x16)
 * 23  (0x17)
 * 24  (0x18)
 * 25  (0x19)
 * 26  (0x1A)
 * 27  (0x1B)
 * 28  (0x1C)
 * 29  (0x1D)
 * 30  (0x1E)
 * 31  (0x1F)
 * 32  (0x20)
 * 33  (0x21)
 * 34  (0x22)
 * 35  (0x23)
 * 36  (0x24)
 * 37  (0x25)
 * 38  (0x26)
 * 39  (0x27)
 * 40  (0x28)
 * 41  (0x29)
 * 42  (0x2A)
 * 43  (0x2B)
 * 44  (0x2C)
 * 45  (0x2D)
 * 46  (0x2E)
 * 47  (0x2F)
 * 56  (0x38)
 * 57  (0x39)
 * 58  (0x3A)
 * 59  (0x3B)
 * 60  (0x3C)
 * 61  (0x3D)
 * 62  (0x3E)
 * 63  (0x3F)
 * 64  (0x40)
 * 65  (0x41)
 * 66  (0x42)
 * 67  (0x43)
 * 68  (0x44)
 * 69  (0x45)
 * 70  (0x46)
 * 71  (0x47)
 * 72  (0x48)
 * 73  (0x49)
 * 74  (0x4A)
 * 75  (0x4B)
 * 76  (0x4C)
 * 77  (0x4D)
 * 78  (0x4E)
 * 79  (0x4F)
 * 96  (0x60)
 * 97  (0x61)
 * 98  (0x62)
 * 99  (0x63)
 * 100  (0x64)
 * 101  (0x65)
 * 102  (0x66)
 * 103  (0x67)
 * 104  (0x68)
 * 105  (0x69)
 * 106  (0x6A)
 * 107  (0x6B)
 * 108  (0x6C)
 * 109  (0x6D)
 * 110  (0x6E)
 * 111  (0x6F)
 * 112  (0x70)
 * 113  (0x71)
 * 114  (0x72)
 * 115  (0x73)
 * 116  (0x74)
 * 117  (0x75)
 * 118  (0x76)
 * 119  (0x77)

Devices on I2C bus "i2c-21":
 * 3  (0x3)
 * 4  (0x4)
 * 5  (0x5)
 * 6  (0x6)
 * 7  (0x7)
 * 8  (0x8)
 * 9  (0x9)
 * 10  (0xA)
 * 11  (0xB)
 * 12  (0xC)
 * 13  (0xD)
 * 14  (0xE)
 * 15  (0xF)
 * 16  (0x10)
 * 17  (0x11)
 * 18  (0x12)
 * 19  (0x13)
 * 20  (0x14)
 * 21  (0x15)
 * 22  (0x16)
 * 23  (0x17)
 * 24  (0x18)
 * 25  (0x19)
 * 26  (0x1A)
 * 27  (0x1B)
 * 28  (0x1C)
 * 29  (0x1D)
 * 30  (0x1E)
 * 31  (0x1F)
 * 32  (0x20)
 * 33  (0x21)
 * 34  (0x22)
 * 35  (0x23)
 * 36  (0x24)
 * 37  (0x25)
 * 38  (0x26)
 * 39  (0x27)
 * 40  (0x28)
 * 41  (0x29)
 * 42  (0x2A)
 * 43  (0x2B)
 * 44  (0x2C)
 * 45  (0x2D)
 * 46  (0x2E)
 * 47  (0x2F)
 * 56  (0x38)
 * 57  (0x39)
 * 58  (0x3A)
 * 59  (0x3B)
 * 60  (0x3C)
 * 61  (0x3D)
 * 62  (0x3E)
 * 63  (0x3F)
 * 64  (0x40)
 * 65  (0x41)
 * 66  (0x42)
 * 67  (0x43)
 * 68  (0x44)
 * 69  (0x45)
 * 70  (0x46)
 * 71  (0x47)
 * 72  (0x48)
 * 73  (0x49)
 * 74  (0x4A)
 * 75  (0x4B)
 * 76  (0x4C)
 * 77  (0x4D)
 * 78  (0x4E)
 * 79  (0x4F)
 * 96  (0x60)
 * 97  (0x61)
 * 98  (0x62)
 * 99  (0x63)
 * 100  (0x64)
 * 101  (0x65)
 * 102  (0x66)
 * 103  (0x67)
 * 104  (0x68)
 * 105  (0x69)
 * 106  (0x6A)
 * 107  (0x6B)
 * 108  (0x6C)
 * 109  (0x6D)
 * 110  (0x6E)
 * 111  (0x6F)
 * 112  (0x70)
 * 113  (0x71)
 * 114  (0x72)
 * 115  (0x73)
 * 116  (0x74)
 * 117  (0x75)
 * 118  (0x76)
 * 119  (0x77)

186 devices detected on 3 I2C buses
fhunleth commented

Interesting. I am not familiar with i2c-20 and i2c-21. Do you know what they're connected to? Something is acknowledging the zero-byte write that's now being used on those addresses, but it's not great that it's causing so much output.

pojiro commented

Do you know what they're connected to?

I will take the time to look into it. I'll get back to you when I know more. Thanks!

  • 👍1
pojiro commented

I looked into it little bit, it relates to HDMI.

following are refs,

This is useful for those who want to hack it, but for those who don't, there seems to be too much to see.
But the i2cdetect command can see them too, so it may be natural for v1.2.x to behave that way.

The downside in terms of usability is that Circuits.I2C.discover_one is more likely to return {:error, :multiple_possible_matches}. It would be nice to have the ability to specify bus number for discover_one.

fhunleth commented

This is unfortunate. Detection by zero-byte write finds more I2C devices that used to not be detectable.

I agree that it would be nice to handle these buses more elegantly. Perhaps if every address reports back, there's a post processing step that removes them all. It doesn't look like there's a good other option from looking at the links.

pojiro commented

I was mistaken.

The downside in terms of usability is that Circuits.I2C.discover_one is

not really there. User could have simply filtered the value (tuple list, [{bus_number, address}, ...]) returned by Circuits.I2C.discover by the bus number.

Detection by zero-byte write finds more I2C devices that used to not be detectable.

Yes, it is clearly a functional enhancement.

Perhaps if every address reports back, there's a post processing step that removes them all. It doesn't look like there's a good other option from looking at the links.

It is a bit noisy all deveices are displayed. But it would be a non-explicit process to hide the devices that are detected.
It might be better to display them as they are.

fhunleth commented

It sounds like the best answer for now is to not do anything. Perhaps one of us will come up with a good idea in the future for how to not list these false positives. If nothing else, this issue documents the behavior.

  • 👍1