Multimaster I2C bus--cRIO issues?

[ddrichman]

Our team is trying to use the cRIO (call it Device A) to talk to an I2C device (call it B) which, itself, is both the slave to the cRIO and the master to a third I2C device (call it C). We have tested our I2C implementations on the two other devices and they work fine when a device other than the cRIO is acting as Device A. We're using C++ on the robot.

When we use the cRIO, however, it seems to interfere with the bus when it shouldn't--when Device B is actively using it to talk to C.

I'm attaching screenshots. You can see on the left the clock pulses/data generated by Device B acting as the master (they're at 400 kHz). Then the cRIO seems to interrupt--the much slower clock pulses (in the 38-50 kHz range) on the right. Note that this three-device communication works correctly for some time (maybe 15 seconds) before the cRIO starts to overlap. (Device B/C communicate every 25 ms for about 25 ms, so while the cRIO's communications fall within the 25 ms off period, everything is fine.)

Does the cRIO play nice with another master on the bus? Is there something we're missing?

Thanks!

[DAQjr]

The cRIO master is not designed to function in a multi-master environment.  However, as you've discovered, if you avoid collisions, it will work fine.  I recommend you either separate the I2C busses or provide some form of external (to the I2C bus) synchronization to prevent collisions.

-Joe

[ddrichman]

All right, thanks for the info. Glad to know what the problem is. Unfortunately we can't separate the I2C busses, but we'll make something work.