Re: i2c and indirect vs. direct config

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

>> On May 30, 2018, at 11:54 AM, Brad Spencer <brad%anduin.eldar.org@localhost> 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 - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org