Two devices on the I2C bus

I have two identical devices on my I2C bus (Pololu MinIMU-9 v3 Gyro, Accelerometer, and Compass (L3GD20H and LSM303D Carrier). One of the devices is jumpered to a different slave address. I can run either of these devices alone on the Due pins 20 and 21. When I put both devices on the bus. I lose all communication with either device.

One interesting clue is that when I am running only one device and connect my oscilloscope to the SCL pin, communication also stops. In other words, the load on the line, just from the oscilloscope seems to push it across some boundary. The other clue is that when the motors on my robot are running, they seem to generate some kind of interference such that the I2C communication is interrupted. It seems like the I2C bus is running on a hairy edge. Do I need to look at changing the pull up resistors which seem suspiciously low in value? Any recommendations?

First, i2c can be finicky. There are a variety of fixes and rules which I won't go into.

Second, a number of people have had trouble with i2c on the DUE. You may wish to see if you have the latest Wire library

There is a fix as late as July 1 of this year.

which is specifically for the SAM architecture.

As <Wire.h> is included by default in either IDE release:
Has this bug been fixed meanwhile already in the 1.6.5 standard edition to be downloaded ?

ArthurD:
As <Wire.h> is included by default in either IDE release:
Has this bug been fixed meanwhile already in the 1.6.5 standard edition to be downloaded ?

No, the Wire.cpp is an old version without the DUE fix. It is a 100 or so lines of code less.

Take note that updating Wire.cpp fixed my i2c communication issues. Since i2c trouble on the DUE is not uncommon perhaps someone with more clout than myself should suggest an update to the powers that be.

well, but that's a shame since IDE 1.6.5 had been released even months later!
Thanks anyway, hopefully it will help and provide me from running into those issues too!

1st, could you please send me a link to the github Wire download site?
2nd, does it include also the avr libs?
3rd, to install: just copy completely into the c:\program files(86)\Arduino\libraries folder ?
(currently there is no [Wire] folder in this libraries folder at all)

ArthurD:
1st, could you please send me a link to the github Wire download site?
2nd, does it include also the avr libs?
3rd, to install: just copy completely into the c:\program files(86)\Arduino\libraries folder ?
(currently there is no [Wire] folder in this libraries folder at all)

The link is in the post.

Note the thread here for Wire.cpp, the header file did not change:

sorry, I don't find the link to the download, just a post about it

but this is not to download anything

ArthurD:
sorry, I don't find the link to the download, just a post about it
Merge pull request #1869 from kevin-pololu/due-wire-available · arduino/Arduino@98d0a72 · GitHub
but this is not to download anything

I am not one to teach of the workings of Github. The code is there on the page, you can view the whole file and copy/paste or get the raw and save that. This is all plain text. Just overwrite the existing.

I actually expected to exist a Wire dir to be downloaded just like for all different libs too.

So there is just one Wire.cpp in the avr directory - but it should be for the DUE which is an ARM, no AVR.
Nevertheless copy and paste it to the avr dir to work with the ARM DUE ?

ArthurD:
I actually expected to exist a Wire dir to be downloaded just like for all different libs too.

So there is just one Wire.cpp in the avr directory - but it should be for the DUE which is an ARM, no AVR.
Nevertheless copy and paste it to the avr dir to work with the ARM DUE ?

I don't understand the environment as it seems wrong as I had described in that thread. I replaced the copy in /avr which is the only version I found and had success with that. I suspect that the IDE has as a list of search locations in looks in for SAM and since it didn't find it in the non existent (for me) /hardware/sam/ it went to avr.

If you need these questions answered I suggest posting in the installation forum of this site. Or you may try creating that directory structure, putting the library there, and checking to see if it does indeed work. I suspect that is correct course. Post back on your findings.

My self, I have some issues with i2c on the UNO as I have 1 wire temp sensors at the end of long runs of cat5. I'll see if the updated Wire library helps with that.

Having read many of the posts on the DUE and i2c, it is clear that many have had intractable problems with the i2c bus, some have given up. That is why I posted back here.

Someone else will have to clean up the SAM environment as it is well beyond my area of expertise. My life in software has been with interpreted languages so anything I might offer at this point would be underinformed. I post now only because I doubt anyone else that knows is following this thread.

I like the DUE but it is clear that it is not fully developed. Still, it represents the future and smokes the UNOs for what is possible.

thanks for your reply!
I now tried the patched cpp file, it compiles when I'm using the DUE but don't fix my own issues.
When I use the patched file to use it again with my Mega, it don't compile any longer.
So the patch is not suitable to work on both platforms, and not sure if it really fixes all ARM related issues.

Anyway, for I2C on ARM/DUE there indeed are (perhaps several different) issues which urgently need to be fixed!