I2C and SPI on the same bus

Question

I have already configured an I2C protocol between a master device (PIC) and two slave devices (sensor ICs). After obtaining the measurements from the sensors I want to store them on an SD card. For that I need to configure an SPI protocol instead. Would it be possible to use the same bus for both protocols. Open I2C, get the data, close I2C and then configure the SPI. Is that possible?

Thank you

EDIT: I2C uses the SDA and SCL pins on the chip. Can I use the same two lines for the SPI and connect the chip select and the data-in lines straight to the PIC?

Answer 1

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

Answer 2

if your i2c device doesn't have an enable, or a cs when you try to talk spi on those pins it may confuse the internal i2c state machine. Best case that would mean your next i2c transaction would be messed up, or it might pull the line low in the middle of a spi transaction. Worst case it could lock the i2c bus. You could probably unlock it but it would have spi to check every read and write (checksum maybe).

Also you have to make sure if you are sharing lines like the output line from your spi device that it does not hold the pin either low or high when it's cs is disabled. Otherwise i2c won't be able to write or will be fighting hard against the driver.

All in all I wouldn't do it myself, maybe you could add a little mux or fet switch to isolate the i2c device in spi mode.

Answer 3

It could work, and what it would boil down to is: could any SPI bit stream potentially look like an I2C start condition followed by any of the slave addresses of the I2C devices you're using. None of your I2C devices will attempt to do anything or interrupt the bus without this initial sequence.

The second part - not sending any valid I2C slave addresses - could be tricky, since you'll want to be abel to write whatever data you like to your SD card.
So you're left with the first part - not producing an I2C start condition during SPI comms.

Since an I2C start is produced when the SDA line changes from high to low while SCL is high, this is the thing you'll need to be aware of.

If you can configure your SPI master so that it only changes the state of SDO when SCK is low then you should have no trouble ....

Answer 4

You can normally mix I2C and SPI on the same pins. I2C only does something between START and STOP.

START is when SCL is HI, SDA goes to HI->LO.

STOP is when SCL is HI and SDA goes LO->HI.

So if you arrange your code such that SDA only changes value when SCL is LO, there will be no problems. The I2C will not notice any SPI transactions. Of course all the SPI devices have thier own individual CS pin, but this is the disadvantage of SPI.

So to spell it out.

You can use I2C devices on an SPI bus. Just connect SCL to SCLK and SDA to SDIO. You can use SPI devices on an I2C bus, just give each chip its own CS signal. Between START and STOP you can only do I2C transactions. The bit timing will be set by the I2C bus,even when doing SPI, ie use 100 or 400kHz Write your routines so that SCL and SDA don't change at the same time. This also removes the problem of SPI devices with rising vs falling clock The "SPI" type devices do have to have a common-able data in and out pins. You can use the same routines for both if you are short of code space. Some SPI devices will need non 8 bit sized transfers. I2C devices have noise filters on the input. SPI devices don't. Bear this in mind if you have long cable runs. You will need to have a reset function that makes sure everything is in the correct state. In particular, some non-I2C serial devices needs some clocks to bring them into a defined state.

https://i2cchip.com/mix_spi_i2c.html