Re: i2c and indirect vs. direct config

[Michael <macallan%netbsd.org@localhost>]

Hello,

On Wed, 30 May 2018 19:42:15 -0400
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.

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