2
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ If you chip select lines available for each device, maybe. \$\endgroup\$ – pjc50 May 11 '15 at 13:19
  • \$\begingroup\$ I am not familiar with spi, but I think it can work: If no bit pattern that you send over the SPI can be interpreted as a valid telegram by any of your sensors. The obvious solution would be switching the sensors off. But if you are stuck with a already existing hardware, that could be tricky. \$\endgroup\$ – jwsc May 11 '15 at 13:24
  • 2
    \$\begingroup\$ PS: look at that, may be closely related: electronics.stackexchange.com/questions/50069/… \$\endgroup\$ – jwsc May 11 '15 at 13:29
  • \$\begingroup\$ very similar question: Using I2C and SPI communication on the same same clock and data lines \$\endgroup\$ – Nick Alexeev Jul 12 '15 at 4:19
2
\$\begingroup\$

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

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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 ....

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.