3
\$\begingroup\$

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: I2C network

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.

\$\endgroup\$
5
  • 5
    \$\begingroup\$ Why not use CAN or CAN FD? I2C causes a lot of problems and 3m is not little for I2C. \$\endgroup\$
    – CFCBazar
    Oct 7, 2020 at 8:26
  • 2
    \$\begingroup\$ Yes, I2C is a trouble maker, especially for wiring longer than 30cm. I think RS485 motors/servos is a good soltuion. \$\endgroup\$
    – tlfong01
    Oct 7, 2020 at 9:31
  • 2
    \$\begingroup\$ yeah, I finally bit the bullet and started converting all my robot comms over to CAN from I2C. After stubbornly clinging to I2C for far longer than I should have. For communicating with multiple devices on a potentially noisy bus, it seems like it's the only way to go. \$\endgroup\$
    – Ocanath
    Oct 7, 2020 at 14:37
  • 2
    \$\begingroup\$ Hi thanks for your answers. Well my driver supports I2C, UART and have some GPIO for reset and fault. In addition, I'm working with an engineer that seems to prefer I2C (high refresh rate), but I'll check with him if it is not too much work. I do agree...CAN seems simpler and better for this application. \$\endgroup\$
    – robotsmith
    Oct 7, 2020 at 14:59
  • \$\begingroup\$ Consider a 10BASE-T1S Ethernet bus. \$\endgroup\$
    – TimB
    Jan 27, 2023 at 3:01

3 Answers 3

7
\$\begingroup\$

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:

CAN Bus topology 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!

\$\endgroup\$
8
  • 2
    \$\begingroup\$ Yes! Also, for a project this complex, find a reliable local mentor if you can. You will learn much more than seeking advice randomly via the web. Because sometimes “you don’t know what you don’t know”. \$\endgroup\$ Oct 7, 2020 at 14:34
  • 1
    \$\begingroup\$ Thanks a lot for the proposition. I actually think that might be better and more robust. The only thing that concern me is the refresh rate of maximum 40 to 125kb/s for the low-speed ISO 11898-3 infrastructure. I hope that satisfy the engineer I'm working with. \$\endgroup\$
    – robotsmith
    Oct 7, 2020 at 15:04
  • 2
    \$\begingroup\$ @Robotsmith that rate is little if you need to e.g. poll a lot of sensors over a single I²C bus. It's plenty for most control jobs, especially if the MCU nodes aggregate information and for example only alert the controller to changed or critical state, on their own, instead of having been asked for every single sensor measurement every time. \$\endgroup\$ Oct 7, 2020 at 15:06
  • 1
    \$\begingroup\$ @Robotsmith another aspect: that's one CAN bus. CAT5 cable has four pairs of cable... \$\endgroup\$ Oct 7, 2020 at 15:07
  • 1
    \$\begingroup\$ @MarcusMüller Sure, I also think that could work, specially since the MCU is close to the driver in this topology. Handling fault, reset and higher level command (e.g. ramp acceleration, add another sensor) should convince my colleague. \$\endgroup\$
    – robotsmith
    Oct 7, 2020 at 15:20
0
\$\begingroup\$

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. \$\endgroup\$
    – Community Bot
    Oct 28, 2022 at 6:33
  • 1
    \$\begingroup\$ If you convert I2C transactions to Ethernet at some point, it simply removes the need for long I2C bus, but you can't extend I2C transparently through Ethernet because I2C transmitter needs data back in real-time. So it would be better to just send an Ethernet packet to request the MCU to do some I2C transaction. And you can't extend Ethernet directly few hundred meters, unless you use fiber, copper is limites to 100 meters. \$\endgroup\$
    – Justme
    Oct 28, 2022 at 7:32
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

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

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