Hello, On Wed, 30 May 2018 19:42:15 -0400 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. I can name a bunch that (as far as we know) don't, but these are all macppc-specific ( as in, i2c-buses controlled by powermac onboard microcontrollers, I also wouldn't bet on ki2c supporting it ) so we're fairly likely to get device info from OpenFirmware, and if not we can still know what's there, to a degree. Generally, I suspect that quite a few 'intelligent' i2c-controllers don't support this kind of thing in a useful way. have fun Michael
