could you educate me?

[mrose17]

hi. i authored a module -- https://github.com/TheThingSystem/node-click-boards -- that uses your module in order to talk to the click boards.

i then used the driver in https://github.com/timbit123/ADXL345 as a template for writing drivers.

thus far i have the ADXL345 (no surprise) and the L3GD20 running, both individually, and together just fine, e.g.,

    gyro: ready
    >>> gyro
    { x: 1028, y: 1028, z: 1028 }
    >>> gyro
    { x: -6426, y: -6426, z: -6426 }
    >>> gyro
    { x: -5398, y: -5398, z: -5398 }
    accel: ready
    >>> gyro
    { x: -2571, y: -2571, z: -2571 }
    >>> accel
    { x: -0.007611649630999917,
      y: 0.022646358911003972,
      z: 0.07873991714399864 }
    >>> accel
    { x: -0.007611649630999917,
      y: 0.022646358911003972,
      z: 0.0015439199439999385 }
    >>> accel
    { x: 0.029518348569000152,
      y: -0.014785639289002006,
      z: 0.0015439199439999385 }
    >>> accel
    { x: -0.007611649630999917,
      y: 0.022646358911003972,
      z: -0.07565207725600054 }

the one thing i have noticed is that sometimes the address for the device differs, e.g., the ADXL345 module uses 0x53 but the corresponding click board is available at 0x1d.

with all that said, could you educate me on a couple of things:

first, there's /dev/i2c-0 and /dev/i2c-1 - what's the difference? are these just adapter numbers without any significance?

second, is it possible to determine which addresses are present? i spent some time hunting around /sys/class/i2c-dev/ and /sys/class/i2c-adapter/ but nothing looks familiar.

third, i'm assuming that the i2c addresses are unique for each kind of click board, so if i had two click boards of the same kind on my system that there would be an address conflict? is that usually solved via jumper or is it a non-issue?

sorry for the lack of clue...

[kelly]

• dev/i2c-0 is just a device file that provides the interface to your hardware.
• You can use the wire.scan function. Or, just type i2cdetect -y 0
• They shouldn't conflict addresses. I think it's up to the manufacturer to prevent i2c conflicts. There is nothing in the i2c spec to deal with conflicts. You could build a translation module if needed, but I haven't really heard of anyone running into this issue.

[mrose17]

thanks. using the scan function, i get [52, 80] on /dev/i2c-0 and [87] on /dev/i2c-1

in hex that's 0x34, 0x50, and 0x87

none of which correspond to the addresses i'm using. very odd.