Go Down

Topic: Due I2C not working (Read 23746 times) previous topic - next topic

projectgus

Hi again Chris,

I just saw your post on the other i2c thread about genuine Dues having 1K pullups, not 1.5K as shown on the schematic. I can confirm this on the genuine Due board I have here, as well.

In that case you're right that things are a bit more borderline, all calculations shown above get 50% worse. ie you can still connect most common i2c slave devices (specced as 0.4V / 3mA) without exceeding the specs, and two or three Dues can be joined together but probably no more. Mixing multiple Dues and other i2c devices all on the same bus is definitely a bad idea without removing some resistors.

I wonder why Arduino specced 1.5K pullups and then went with 1K in the factory!

- Angus

chriskner

projectgus ,

All True...  Except for if you produce a design based to operate just under the maximum allowed specifications, then you are making a product that has inherently reduced reliability and longevity (for no good reason).  Stay well away from the max specs for catastrophic electrical failure, and you'll be much, much happier.

Presumably, the DUE was designed for experimenter's and novices, using 'typical' (common) interfaces.  While pushing the speed boundaries of the I2C bus is a possibility, anyone serious about it would most likely use an I2C buffer with rise/fall time acceleration (and not rely on a uC's raw dio pin for drive capability).  Considering the intended audience, the DUE design should error on the safer-side of electrical failure.

I truly believe that the pull-up resistor choice on the DUE was a mistake, and it would have been done differently if they had the chance to do it all over again.  These things do happen.

Also, remember, the installed pull-up resistors are 1000 ohms, not 1500 (as shown in the prints).  Two DUE's connected together puts the I2C dio pins right near max spec.

Regards,

Chris

projectgus

#32
May 28, 2014, 02:52 am Last Edit: May 28, 2014, 02:57 am by projectgus Reason: 1
Hi Chris,

I agree with you that the 1K thing is definitely a mistake, compared to 1.5K as per the reference design.


All True...  Except for if you produce a design based to operate just under the maximum allowed specifications, then you are making a product that has inherently reduced reliability and longevity (for no good reason).  Stay well away from the max specs for catastrophic electrical failure, and you'll be much, much happier.


I agree also, but the limits we're talking about here aren't the limits for electrical failure. They're just the limits for normal operation with VOL<=0.4V (6mA). Exceed that limit and there's the next limit for VOL<=0.6V (9mA), also specified by the manufacturer as safe ("Relaxed mode").  Go past that and you've exceeded the safe specifications. The datasheet doesn't specify what the absolute limit is but you know for sure you can at least get to 9mA without compromising. Although I agree you want to design in headroom under normal operation.

Quote
Two DUE's connected together puts the I2C dio pins right near max spec.


This configuration puts the Due near the 6mA limit where the low voltage level may rise to 0.6V. No risk to the devices unless more than 50% more current draw appears from somewhere, to push past the "Relaxed Mode" specification of 9mA.

Of course if you connect some other i2c device to the same bus on top then it might not work, due to the low voltages possibly now being higher than 0.4V.

- Angus

johnflux

This is a confirmed bug in the arduino Wire library:  https://github.com/arduino/Arduino/pull/1994

Specifically:

Download:

https://raw.githubusercontent.com/bluesign2k/Arduino/d8d6d62853a5308c21b95dad4bdd64e358e857cc/hardware/arduino/sam/libraries/Wire/Wire.cpp

And overwrite in your arduino installation: hardware/arduino/sam/libraries/Wire/Wire.cpp

For me, this just fixed i2c on the Due.

Other people said that it gave a compile error - I don't know why.

sethismyfriend

I tried the wire.cpp fix on my Due using the Adafruit motor sheild v2 - and just one motor and it fails as soon as the motor starts spinning - which makes me think something in the hardware is failing using the i2c protocol as these shields operate with i2c in version #2.

Go Up