SPI / I2C pin sharing?

jazzed

What would be the consequences of having SPI data/clock share I2C data/clock pins?
Would the SPI protocol ever cause and I2C device to respond?

Haven't looked at this in detail, but it seems to have been a sub-topic in a thread last year.
The I2C pull-up resistor on SDA would cause some problems for SPI if it was too strong.

Mike Green

The SPI protocol could cause the I2C device to respond

BigFoot

I wouldn't mix the two, there is no telling what might happen ...

Why not use the Props I2C port as is, and use four other I/O pins for the SPI ?

jazzed

Thanks. Being lazy today. Prop pins are a scarce, precious resource.

Cluso99

You can share one of the pins, but not both. This is because you can hold the other pin so that nothing valid is seen. Typically, the CLK pin would be shared.

Phil Pilgrim (PhiPi)

As long as SDA does not transition low while SCK is high, there should be no problem. An I2C transaction does not begin until SDA is pulled low while SCK is high. It ends when SDA goes high with SCK high. So, if SCK is pulled low first, while SDA is high, and SDA is changed only while SCK is low, you could actually use both lines for your SPI interface.

-Phil

jazzed

Phil Pilgrim (PhiPi) wrote: »

As long as SDA does not transition low while SCK is high, there should be no problem. An I2C transaction does not begin until SDA is pulled low while SCK is high. It ends when SDA goes high with SCK high. So, if SCK is pulled low first, while SDA is high, and SDA is changed only while SCK is low, you could actually use both lines for your SPI interface.

-Phil

That's what I was looking for :-) Writing a SPI driver like that is probably painful and inefficient, but if it works that great :-)
Still, I've pretty much settled on sharing the SCL pin. That way people don't get in trouble using any old SPI driver.