Hacker News Reader

Comment by jpm_sd | Hacker News Reader

I2C is not a wired network standard! It's designed to be used between chips on the same PCB, typically with the same power supply rail (although level shifters are available) and the same ground reference plane. Yes, ground planes matter for best performance.

Breakout boards are meant for a quick test. Then you're supposed to design a PCB with the devices you need all in one place. SparkFun spaghetti will only end in tears.

The other thing that sucks about I2C is that you never know what hard-coded addresses you will be limited to, until you've selected all your parts, dug into the datasheets and then discovered the inevitable collisions.

In 20 years of PCB design I think the largest number of I2C devices I've had on one bus is maybe 30? And that was pushing it.

View on HN

What sucks the most about I2C for me is the fact that the bus can get stuck if the master device resets during a transmission. In which case the slave device will keep the SDA line busy while waiting indefinitely for clock pulses. Yes, you can probably send dummy clock pulses to finish the frame and get SDA released, but that's just a pain to code properly.

SPI is so much more reliable with just two extra pins, I usually don't even consider I2C anymore.

Yeah that's pretty disappointing. Gotta implement a "bus clear" feature in any system that relies on I2C working consistently.

Slave devices that rely on clock stretching are a total pain in the ass, as well. Tend not to play nice with other normal devices. https://www.i2c-bus.org/clock-stretching/

The main thing I use I2C for in recent designs is multiple channels of power monitoring, e.g. using the INA226. I agree that SPI is preferable for sensors that support it.

https://www.ti.com/product/INA226

And I'm currently working with the INA229, its SPI cousin I guess :) Those chips are really nice, I'm trying to use the alert feature as a configurable overcurrent trip protection, as well as overvoltage device protection.

https://www.ti.com/product/INA229

SPI requires 3 wires plus a Chip Select for each device on the bus. That 30 device network under discussion suddenly needs 33 pins. That's more pins than any processor I've used in the last couple of years.

I mean I guess we could use an i2c GPIO expander to get extra lines. I bet that would be "fun" to get right.

You'd be using an address decoder for so many devices unless you have a MCU with an abundance of i/o lines (perhaps a soft-core within a FPGA).

You can use a demultiplexer to turn e.g. 4 pins into 16 chip select. But the fact that the number of wires has to grow at all to accomodate additional devices is certainly a big downside compared to I2C, and for wired networks that basically makes it impossible to daisy chain devices.

If you had 30 SPI devices, you'd probably use a small FPGA to address them all (produce all the chip selects as needed). Basically, write an integer (e.g. 5 bits would do for 30 selects) and a strobe and you're good to go. No address conflicts, ever. And very fast.

Many MCUs also don't handle SPI well (via DMA) or have bugs in peripherals. So the only viable way is bit banging and that is difficult to make faster than I2C. I am considering implementing SPI on FPGA to connect with devices and then transmit to/from MCU using "SPI" dialect that works with that MCU.

What kind of issues have you found with SPI peripherals? I've rarely found issues with SPI, certainly it's a peripheral which is far less buggy on average than I2C, where there are some absolutely awful implementations.

Agreed. I’ve seen plenty of I2C devices with problems. I’ve seen very few SPI devices with problems.

I've seen much more buggy I2C peripherals than SPI (ST, I'm looking at you).

SPI is usually very stable. Here it's being used to generate VGA signals: https://www.artekit.eu/vga-output-using-a-36-pin-stm32/

SPI is however not useable as a bus. You need a specific chip select pin line for every chip you communicate with. But yes I like SPI much better as well.

It works as a bus when the chip manufacturer is nice enough to add a couple of address pins. Unfortunately not all that commonly done.

I have never seen that actually. But also have never looked. I have used a binary decoder to achieve the same thing though.

E.g., HMC983, and some of the former Peregrine (now Toshiba) parts.

You could always use an i2c gpio expander <ducks>

This can be detected and usually just mux scl to a gpio and cycle until the bus is recovered. The real issue is if a device decides to hold scl low forever. At which point it's recommended to power cycle devices on the bus until it recovers.

Just power-cycle the slaves.

I like that phrase, "Sparkfun spaghetti". I shall be stealing it.

I submit “Adafruit anarchy” to go along with it.

Those little breakout boards are such a liberation for us oldsters who can't handle the tiny little surface mount components. I've gotten stuff well into development with an ExpressPCB loaded with breakout boards, and the engineers can turn it into a real board with real code in a jiffy while the prototype is being used for testing.

Oh, don't get me wrong, the Sparkfun and Adafruit breakout boards are indeed a boon for prototyping. It's just that many hobbyists (myself included) get as far as the prototype working as intended, and call it a day. And with "Sparkfun spaghetti" and "Adafruit anarchy" I now have phrases to describe what the inside of those prototypes often look like.

If you use multiplexers you can connect a lot more devices (upto 64*254 = 16256 I think) on a single bus.

https://learn.adafruit.com/adafruit-tca9548a-1-to-8-i2c-mult...

You could of course design your own multiplexer with more bytes of multiplexer address space and extend the concept indefinitely. I wouldn't recommend it, but it's possible.

64*127 = 8128, normal i2c is limited to 7 bit addresses. There are extended i2c addressing setups but I believe that requires every chip involved to support them.

The third thing that sucks about I2C is a little thing called Clock Stretching which can completely blow up your latency when reading sensors. The last company I worked for had to design a sensor out because it would stretch clocks unpredictably for several milliseconds, which was enough to blow our latency requirement to maintain real-time operation.

https://www.i2c-bus.org/clock-stretching/

Certainly not exhaustive, but fairly handy for hobby projects: https://learn.adafruit.com/i2c-addresses/the-list

Reply on news.ycombinator.com