Using I2C and SPI communication on the same same clock and data lines

Question

I am using a PIC18F25K80 with multiple slave devices. All of them uses I2C except one. What i want to know is that can i first use I2C with the devives that uses I2C and then close I2C, change clock speed and switch to SPI mode ? Is this poosible without causing a conflict ?

Note - When I am in the I2C mode the chip select is set so that the device using SPI mode is inactive. Only after finishing the I2C mode I am making the device active.

Answer 1

It is possible to share I2C and SPI pins if code which uses each interface can guarantee that devices using the other will never see any sequence of pulses that would cause them to take any action or output any data. To avoid having a sequence of pulses mistaken for an I2C addressing sequence, one should ensure that there are never eight consecutive low-high-low transitions on the I2C clock wire in which the state of the I2C data wire doesn't change. When using a typical SPI master and wiring CLK to SCK and MOSI or MISO to SDA, such a guarantee may not be met since clock and data would change roughly simultaneously, and how the I2C device interprets them would depend upon which signal it saw change first.

If hardware is sufficiently configurable that one could wire CLK to SDA and MOSI to SCK, however, then things could work safely on a typical SPI implementation provided that one avoids I2C addresses containing all zeroes or all ones, since it would be impossible for MOSI to go from low to high and then high to low more than once (much less eight times) without intervening transition on CLK.

One caveat is that some devices try to "auto-detect" the attached interface, and some auto-detection methods may regard signal sequences which would not be defined in one interface as indicating that they should use a different interface. It should be possible for devices to auto-select interfaces through strapping without such false detection if some interfaces which use a subset of the wires require other wires to be strapped together (e.g. for a device which supports SPI and I2C, wiring both /CS and CLK to SDA, and MOSI to SCK) but many devices use crude and unreliable detection methods which may wreak havoc even when they are used with other devices of the same type.

Answer 2

I believe the circuit shown below will accomplish what you need. One I2C device is shown, along with two SPI devices. The circuit can be easily expanded to any number of I2C or SPI devices. The additional logic gates required are shared between all devices; there are no logic gates needed per device thus keeping parts count down. Only one extra lead is needed above the maximum four (plus SPI chip selects) needed for the standard I2C/SPI interfaces.

On the PIC18F25K80, SCL (I2C clock) and SCLK (SPI clock) are on the same pin, and SDA (I2C data) and SDI (SPI data in) are on the same pin. SDO (SPI data out) is on a pin by itself.

There are two issues: one is to disable the I2C device(s) when an SPI device is selected (and conversely, to disable the output(s) line of the SPI device(s) when they are not selected); and secondly to deal with the issue of pull-ups on the I2C lines when the SPI SDO lead is driving the SDA/SDI line on the microcontroller.

To handle the first issue, all of the SPI chip selects are AND'ed together. I am showing a 74HCT21 four-input AND with two inputs unused; this could be expanded to any number of chip selects.

If any chip select is 0, then the output of the AND gate is 0, which disables the analog switch, so the SCL clock from the microcontroller is disabled from reaching the I2C device(s). If all chip selects are 1, then the output of the AND gate is 1, enabling the analog switch, so the SCL clock is passed bi-directionally between the microcontroller and the I2C device(s).

For the second issue, a pullup is provided on the SDA pins per the I2C spec. Of course this puts a pullup on the SDA/SDI pin of the microcontroller as well. Since SPI devices are not setup to drive against a pullup, I added a 74HCT07 open-collector buffer to take care of this issue.

The buffer is preceded by an OR gate, with one input from the same lead that enables/disables the I2C clock. So that when the I2C interface is enabled, the OR gate is always asserted, keeping the open-collector output of the buffer high.

Answer 3

I don't think so. A simplistic sharing the clock and data lines between SPI and I²C devices doesn't look like a good idea. Such sharing can introduce a failure mode, that can corrupt the SPI communication.

Imagine that MOSI/SDA and SCLK/SCK are shared. We are communicating to the SPI device. The I²C slave devices “see” the clock and data as well. It's possible that some random combination of bits in the SPI data will look like a start condition and slave address to the I²C device. The I²C slave device will interpret this as a beginning of an I²C read transaction, start transmitting, pulls the MOSI/SDA low. This would corrupt the SPI communication.

So what can be done. You have one SPI device that requires high speed communication, and many I²C devices that can do with relatively slow communication. A situation like yours is not uncommon. Consider these:

• Use the hardware peripheral (MSSP in the PIC) for SPI. Bit-bang I²C on a pair of separate digital I/O pins.
• Use MSSP for SPI communication. Connect the I²C devices through an SPI-to-I²C bridge (SPI slave, I²C master).
• Use the MSSP for both buses. Put the I²C devices on their own branch that has a switch, which can disconnect the I²C devices from the bus during SPI communication.
• Look for a pic with 2x MSSP peripherals.

edit:
The subject of using the same MSSP for SPI and I²C has come up in the forums a few times over the years: CCS forum 2003, PicList 2005 (solid discussion), Microchip's own forum 2012, EE.SE 2012