Electronic – I2C and SPI on the same bus

Some I2C slave devices use hardware handshaking, which entails having slave devices which are not immediately ready for a cycle holding SCK low until they are, and having master devices which release SCK wait until the line actually rises before processing the next cycle. Such devices will not coexist nicely with an SPI bus.

If the I2C device won't accept 00 or FF as an addressing byte, one may avoid any possibility of interference by either configuring the SPI bus so the data state will only change when the clock is high, or else by ensuring that the I2C device will see any falling clock edges as happening after any associated data change. Depending upon what sort of SPI device one is connecting to, that may be the natural state of affairs or it may be somewhat awkward. If one is bit-banging SPI, there will generally be no difficulty ensuring that the sequence of highs and lows on SCK/SDA will continually reset the I2C chip without it ever being able to say anything. If one needs to use hardware SPI but can bit-bang I2C, wiring SCK to something other than the SPI clock may allow one to avoid trouble [e.g. if one wires SCK to MOSI and SDA to MCK, then it would be impossible for SCK to see more than two consecutive cycles without having a rising or falling edge on SDA occur while SCK was sitting high].

An important caveat with this approach, however, is that many I2C devices do not specify their behavior if transitions on SCK or SDA happen above a certain speed, and SPI devices are often run far above the speeds that I2C devices can accommodate. If practical, it may be good to either have I2C share one pin with SPI but not both, or add some hardware to ensure the I2C doesn't see fast signals on both SCL and SDA