I’m using the PR54-3 with a Particle Argon with a PR33-14 (8 Ch ADC) and PR33-35 (12 Ch ADC) connected. I also use the PR54-3 board’s 3.3v I2C screwdowns for communication with a pair of GPIO devices.
I have build 4 devices with the exact same configuration, but on one device, I have issues with my GPIOs that share the bus with the ADCs. I can poweroff, then disconnect the ADCs, repower and the GPIOs work fine. Poweroff and reconnect either or both ADCs and power back on, the GPIOs act screwy.
I have replaced the PR54-3, the argon inserted on that board, the GPIOs and the ADCs but the problem persists. I’ve also disconnected every line into the ADCs to see if the problem was coming from that, but no change.
Have you experienced these ADCs polluting the 3.3v I2C lines from the Particle Argon? Again I’ve used this configuration before with no issues, and actually have an identical installation onsite that is working fine. But the only constant I can find is: ADCs are connected and the GPIOs get screwy. Any thoughts on this?
I think we may have a miscommunication, the GPIOs I’m referencing are a separate I2C Device that use the SCL/SDA screwdowns on the PR54-3. I’ll attach a diagram in just a minute to show the setup more clearly.
Our devices simply shift the I2C bus levels from 3.3V to 5V in preparation for cabling. In this process, we use I2C pull ups as required by the I2C specification for I2C Master controllers. The possibility does exist that on-board pullups in combination with your I2C external devices are pulling the I2C bus too low, which would interfere with communications when connecting to the GPIO/I2C screw terminals.
With regard to I2C address 0x40 and multiple devices sharing the same address: I have experienced excellent results with this if the device is a output device (write data to the device). If the device is reading inputs or returning any kind of data back to the master I cannot imagine any possible way they could be synchronized without data conflicts unless it is a highly specialized device that does not follow conventional I2C protocol. If this is the case, you might want to consider a I2C multiplexer to physically switch between your GPIO expander devices and NCD devices.
Of course when integrating I2C devices, I always start by disconnecting everything and introduce one device at a time, both physically, and in code. I would start with the easiest devices first and prove they are working before introducing the next device.
I appreciate the in depth response. The shared address devices are output only hence why we’ve gotten it to work. I’d also be interested to hear what you recommend for an i2c multiplexer as I’ve never tried one out.
In regard to the problem we were seeing: we ended up finding a bad solder connection on our gpio device that could cause a very intermittent instability on the ground supply, this was then exasperated by adding more devices to the common ground. Correcting this solved our issues.
So we can mark this as resolved and the problem being outside the scope of NCD.
Thanks again for your time, and do send any suggestions you might have on multiplexing i2c
Hi Ryan,
Multiplexers can be found at the link below, the first 2 products are 4 and 8 channel multiplexers. These are really cool products because they can be used to route I2C data to any of the selected ports (the other ports will remain disconnected). They use a I2C address (jumper selectable), so many of these can be cascaded together for large arrays if needed. This can easily resolve the problem of needing to access several different I2C devices that share the same I2C address. This is our go-to product for in-house testing and troubleshooting of I2C devices that do not want to play nicely together. There are some other interesting devices in this category as well. Hope this helps.
Ryan https://store.ncd.io/?fwp_product_type=i2c-enhancement
