4
\$\begingroup\$

Now I have ten accelerator sensors (ADXL345) connected to only one PIC16F887 using I2C. The problem is ADXL345 only has 2 I2C slave addresses configurable. So it brings conflict.

I know NXP does provide a I2C multiplexer that work around this kind of issue, but I have ten sensors. So it seems of no help.

\$\endgroup\$
2
  • 2
    \$\begingroup\$ Did you consider bit-banging the I2C interface? It is not that hard, but it will be slower and use more resources (CPU, Flash). \$\endgroup\$
    – Wouter van Ooijen
    Nov 5, 2014 at 14:55
  • \$\begingroup\$ Thought of bit banging, but quit because of not adequate to the minimum speed requirement. \$\endgroup\$
    – longtengaa
    Nov 9, 2014 at 16:41

2 Answers 2

Reset to default
6
\$\begingroup\$

Ten ADXLs would be 5 pairs with the ALT_ADDRESS pin.

NXP do 2, 4 and 8 channel I2C switches, so you could use an 8-channel switch, which would allow you up to 16 ADXLs.

Alternatively, you could roll your own switch in an ASIC or CPLD.

A third option would be to ditch I2C and use the SPI interface on the ADXL. This would mean more pins from the PIC to select the 10 chips, but couple it with a 4-to-16 decoder and you can select any one of them to communicate on the SPI bus with just 4 pins from the PIC (would allow up to 15 ADXLs if you reserve one address for "no chip selected").

\$\endgroup\$
6
  • \$\begingroup\$ Or put some shift registers on the same SPI bus that you use to control the sensors. The shift regs control the sensors' select lines, so that you only have one select line from your MCU to all the shift regs. Connect the shifters in series with each other and with your sensor array. Careful reading of the timing diagrams should reveal a way to make that work, with the next sensor address inherently included in the protocol. That would give you as many sensors as you need with only 4 lines from the MCU. I would separate all of that code into its own section to make it easier to maintain. \$\endgroup\$
    – AaronD
    Nov 5, 2014 at 17:19
  • 1
    \$\begingroup\$ I used a similar scheme to use an unlimited number of digital I/O via SPI. I used the one chip select to control all of the load/latch inputs of the In/Out shift registers so that I could capture everything at once and display everything at once, without seeing them shift. I had to send an entire byte just to have a clock available to load the inputs, so I ended up with a dummy byte that falls off the end of the output string. But it works, and I'm happy with it. IIRC, the shifters that I used weren't even advertised to use SPI, but the bit-banged datasheet was close enough to work anyway. \$\endgroup\$
    – AaronD
    Nov 5, 2014 at 17:31
  • \$\begingroup\$ @AaronD True - I have used MCP23S17 IO expanders to drive other devices on the same bus before. \$\endgroup\$
    – Majenko
    Nov 5, 2014 at 17:46
  • \$\begingroup\$ I looked at IO expanders. The shifters were cheaper. By quite a bit actually. And it was more obvious that they could be daisy-chained ad-infinitum to behave as one giant shift register that behaves as a unit according to the same datasheet. \$\endgroup\$
    – AaronD
    Nov 5, 2014 at 17:54
  • 1
    \$\begingroup\$ @AaronD The advantage of IO expanders though is you can control each pin individually, you can use some pins as inputs, they have pullups, pulldowns, interrupts, etc, and you can chain up to 8 of them together on one CS pin for 128 IO ports, and still use just 2 bytes to reference one port instead of shifting the entire chain's worth of data. You can then be using some of the pins for other things besides just controlling chip select lines. \$\endgroup\$
    – Majenko
    Nov 5, 2014 at 18:03
0
\$\begingroup\$

While it would probably be possible to kludge together some additional hardware that would only let one I2C device see each transaction, doing that without relying upon any undocumented behaviors may more work than using SPI. It might be possible to use a one-of-ten selector to drive the address-select wires on the devices and only use one address when talking to any of the devices [the one-of-ten selector would control which device would respond to that address], but I didn't see anything in the datasheet which would indicate exactly when the device would sample that pin. Still, if you want to use I2C, and can either find something that documents that the address pin can be used in such fashion, or are willing to gamble that if it can be used that way in today's chips, it will remain valid on future runs, that might be the cleanest way to do it.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.