Re: i2c and indirect vs. direct config

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

Mouse <mouse%Rodents-Montreal.ORG@localhost> writes:

>> Your points about explicit config make a lot of sense; reminds me of
>> qbus and isa bus where you have to know.
>
> Well, except that on Qbus and ISA, most devices can be probed
> relatively harmlessly.  That is, asking a driver "there might be a
> device you handle at this address, check it out?" is a reasonable thing
> to do.  There certainly are exceptions, a few cases of devices X and Y
> such that having device Y's driver probe for a Y at A when there's
> really an X at A will do something unfortunate to the X.  But they are
> few and rare.
>
> As I read thorpej's mail, that's far less true of i2c.
>
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>  X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Can "far less true" be quantified somehow??  I seem to remember one
known device that didn't like to be probed, something on a Lenovo laptop
I think, but I don't remember if it was a read cycle or a write cycle
that made the device upset.  Or something else..


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.




-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org