3 ms·
I think the thing I've seen that's the hardest to detect is reflections on the falling edge of scl double clocking. It's been a long time since I've seen it ma
by mcshicks 5y ago
I think the thing I've seen that's the hardest to detect is reflections on the falling edge of scl double clocking. It's been a long time since I've seen it maybe more modern controllers slew rate limit the falling edge. But definitely the i2c device at the end of a long cable is not a great idea.
- xondono 5y agoIf you are getting reflections at 400Kbps, you either have another problem or are way out of the standard. There’s a reason for things like RS422/485. The hardest bug I’ve seen on an I2C bus was an implementation that every now and then dropped the lines to GND for a small period (~50ms). All I2C devices were working correctly, but because of supply chain reasons we had to introduce a PN change that was on paper 100% compatible. The new PN was a SMBus device, and guess how SMBus signals a reset...
- mcshicks 5y agoReflections are a function of the edge rate, i.e. driver strength, not the clock rate. https://en.wikipedia.org/wiki/Signal_reflection https://en.wikipedia.org/wiki/Signal_reflection
- xondono 5y agoI know, but clock rate tends to be a good proxy, especially im cases like this. For a bus like I2C there’s basically two possibilities: 1. You are using a part with a clock rate that extends clock rate over the standard, which means you have very small pull ups on the lines because that is what the datasheet recommends for that speed (thus your rise time gets too short). 2. (And this one is way more likely) you are using I2C to communicate over a long cable.