Jason Thorpe <thor...@me.com> writes: >> On May 30, 2018, at 11:54 AM, Brad Spencer <b...@anduin.eldar.org> wrote: > >> Does the techniques mentioned in these offer any hope of determining the >> presence of an actual device at a particular address on the bus in a >> harmless manor: >> >> http://forum.arduino.cc/index.php?topic=61520.0 >> https://electronics.stackexchange.com/questions/76617/determining-i2c-address-without-datasheet >> >> The second, in particular, simply does a start+address+stop.. if the >> response to the address was ACK there was a device, otherwise, there if >> it was a NAK there wasn't anything there. I don't know how well this >> works in in practice. But it would seem to be something that would not >> be able to upset a device. > > That’s a great idea, actually. It would certainly help the ghosting problem. > Perhaps we can centralize the logic into a helper function that does the > START-address-STOP handshake and also filters the address against a list of > valid addresses passed by the driver (in general, i2c devices can’t be at > arbitrary addresses). > > -- thorpej
A zero length write would probably also work and should be just as safe, although I am not sure that every i2c controller supports that sort of thing. The RPI had a KASSERT() that wasn't needed that would have paniced upon trying such a thing. It was removed when the si70xx driver was added to the tree because that driver needed to be able to do that a zero length write, then wait before doing a read. If clock stretching support existed in the i2c infrastructure, this would not have been required. I submitted the PR that became the am2315 and si70xx drivers that are in the tree and I didn't like the ghosting problem when I was doing the development, so those drivers have some additional stuff added to their match function to do something like the start+address+stop thing, just not in any sort of general way. -- Brad Spencer - b...@anduin.eldar.org - KC8VKS - http://anduin.eldar.org