I2C differential network architecture using PCA9615

Question

I'm building an architecture for a large scale robot (3x3meters) and I would like to build a specific architecture around I2C differential to control motors drivers (this should be noisy).

My problem is, in order to avoid high cost cables and connector, to build kind of star I2C network using PCA9615. Since star network are not really recommended on RS485 for instance, I guess so it should not be ok with differential I2C.

So my idea is to split network like this:

My main board will collect all feedback from several PCA9615. All twisted lines will be maximum 3m long.

I guess using a I2C switch will solve my solution (for example TCA9548A).

But since I don't have experience in I2C network, I rather ask ;)

So my question is: could it work? Is there a simpler solution?

Thanks a lot !! :)

Note: If I'm not clear enough, please feel free to reprimand me.

Answer 1

You'll find that modern cars are essentiall 2.55m × 3m robots containing a human driver.

The guys producing millions of them have agreed to use CAN, because the combined cost of cabling + CAN-capable controllers + connectors is cheaper than the effects of having the unreliabilty of rolling something based on I²C or their own bus inventions. Use CAN.

Low-Speed CAN is specified to work in star topologies, or mixtures of stars and long buses:

^{Figure by EE JRW}

It works over the cheapest of all data cabling: 120Ω Twisted pair, aka "cheap network cables". The fact that even shielded network cable with high bandwidth is cheap is undeniably a large plus in applications with multiple motors in large devices that might even see RF ground differences.

CAN-capable microcontrollers cost 2€ in single quantities, so I'll go with: if you need to connect I²C devices, keep I²C short and linear, and connect them to such a microcontroller close to their position, and then connect that via CAN. This, by the way, also isolates faults very effortlessly, and makes writing a controller easier: your central node can issue "high-level commands" to the CAN microcontrollers (like: Drive the motor until you hit the stop switch or temperature increases beyond 80 °C) instead of having to do a load of I²C commands centrally. Makes debugging easier, and atop of that, easier to mentally divide development workload – you know can be either in the mindset "low level hardware driving" or "high level control design", but don't have to do both at once. You can even have a set of "CAN node" engineers and a set of "control engineers" and they only have to agree on a simple set of commands. Yay!

Answer 2

CAN can work, but so can I2C and it is a mistake to say it will never work. If you understand what you are doing and understand integrity problems and how to avoid them, you have a fair chance of success.

Philips (today NXP) did two larger books on I2C that actually tell how to do this correctly. Unfortunately I don't have mine anymore, so the titles are out of my memory, but you might be able to find them on NXP's website.

You can also cheat over longer distances, by using Ethernet as carrier. Then you could go for 100s of meters with I2C.

Answer 3

I²C is fine for fetching some temperatures or EEPROM data on a PCB. But getting fancy with I²C is asking for trouble.

I've also used those PCA9614/5 chips. But I considered them as a necessary evil. In my case it was about handling non-critical data: A change to the physical design of a product made it necessary to use those differential transceivers, because it wasn't practical to change the already existing and certified firmware.

I would strongly discourage you from using I²C to handle critical features of a product like controlling motor drivers of a robot.

Because of its architecture, I²C has the tendency to hang itself when a slave is in an unexpected state due to a firmware bug or an EMI event, for example.

I²C is simply not an inherently robust bus system.

Most problems can be handled with very careful firmware design, of course. But like I said: It's asking for trouble.