Hacker News Reader

Comment by robotjosh | Hacker News Reader

I've seen a lot more hardware problems involving i2c than involving spi. If an i2c device fails its a pain because it is not apparent which chip on the bus failed. If I do have to use an i2c device I try to avoid having more than one on the same i2c bus. Spi might require more tracks but tracks are cheap and hardware problems are expensive.

View on HN

Very true. I2C devices are prone to locking the bus. Its a failure mode that SPI does not suffer from due to its use of chip-select (and hence is completely controlled from the master). This is a real drawback in creating reliable systems using I2C.

I2C peripherals in microcontrollers tend to be finnicky as well, because the interpretation of certain events depends on the device and so the interface between the hardware and sofware winds up very complex (and prone to error, I've had to reset an I2C peripheral at the start of each transaction in order to get it to work properly).

Terminator resistors! although it's not rocket science they can be quite PITA to figure our during development phase when you are testing different i2c components with different impedances

Sometimes it's easier just to periodically reset I2C slave devices from the bus master (either with a dedicated reset line or just power-cycling the chip using a FET)

If you just power down by running the i2c slave power through a FET, either the i2c-slave might pull down the i2c lines in an uncontrolled fashion.. or the i2c-slave might still be powered through the i2c SDA/SCL pullups.

So if you really want to decouple a i2c slave for the purpose of resetting it, also run the i2c lines through a CMOS switch, which of course will complicate this even further. Then better don't use the buggy i2c device at all.

Reply on news.ycombinator.com