5
\$\begingroup\$

We have a product which uses PIC18F4520, and we used some devices like LCD driver and so on, that all use I2C bus to comunicate with the micro. But now we want to add a couple of AD5504, which is a DAC with a SPI interface. We now have a question as to whether they could share the same connection with the I2C bus or not.

Do you have a good suggestion about it?

\$\endgroup\$
  • \$\begingroup\$ If I understood well, you want to reuse the SCL as the SPI clock, the SDA as the MOSI, and reserve two other pins from the PIC as CS and MISO? \$\endgroup\$ – fceconel Nov 29 '12 at 11:50
5
\$\begingroup\$

Another option would be to use an SPI to I2C bridge chip. This would essentially allow you to add a chip select for your entire I2C bus. One such option is shown below.

http://www.silabs.com/products/interface/spitoi2c/Pages/default.aspx

\$\endgroup\$
4
\$\begingroup\$

An I2C device will silently ignore everything that happens on the bus until it sees a falling edge on SDA while SCK is high, followed by eight low-high-low cycles of SCK during which SDA never changes while SCK is high, and where SDA switches state on certain transitions while SCK is low. Therefore, an I2C device may safely share a bus with devices using some other protocl if the above sequence of events can be guaranteed never to occur except when trying to talk to the I2C device.

It would be possible (and not at all difficult) to have a "bit-bang" software SPI implementation ensure that the above sequence of events never occurs. Hardware SPI implementations, however, will often not allow for such a guarantee. Typically, the data output will by design change either at the same time as the clock rises, or at the same time as the clock falls. If the data wire were consistently to change state after the rising edge of the clock wire or before the falling edge thereof, there would be no possibility of SPI data being mistaken for an I2C start and addressing sequence. If the signals change at the same time, however, it would be possible that an I2C device might see some transitions happening before the clock edge and some happening after, in such a way as to be interpreted as an I2C address sequence.

\$\endgroup\$
  • \$\begingroup\$ Supercat , very interesting, I will try it soon . but we have already change the micro on new production .thanks anyway. \$\endgroup\$ – qing zhang Dec 4 '12 at 12:39
3
\$\begingroup\$

If this AD5504 thing (you didn't provide a link) is another IIC device, then everything should be fine. If it is something else, like SPI, then no, that won't work. A SPI device can be made to ignore MISO and MOSI by not asserting its slave select, but a IIC device will get very confused by normal MISO and MOSI signals on the SCL and SDA lines. Even a cursory look at the IIC spec would have revealed that.

\$\endgroup\$
  • \$\begingroup\$ Yes, it looks like SCK and SCL share pins on that PIC. \$\endgroup\$ – Chris Stratton Nov 28 '12 at 20:20
  • \$\begingroup\$ thanks ,it is very helpful. but how can we figurout the issues, we don`t want to change the code too much , make the works less ,and saave the money:) \$\endgroup\$ – qing zhang Nov 28 '12 at 22:38
  • 1
    \$\begingroup\$ Do one or the other in firmware, assuming the processor is the master in both cases. Both are pretty easy, but SPI is probably the easier of the two to implement in firmware. Really, this is quite simple. That way you can use whatever pins you want for the firmware-implemented bus. \$\endgroup\$ – Olin Lathrop Nov 29 '12 at 0:26
  • \$\begingroup\$ thanks, Olin Lathrop ,we are going to switch the PIC18F4520 to PIC18F46K22 which has 2 I2C and 2 SPI interface , is it good way or not . please advice. thanks again! qing \$\endgroup\$ – qing zhang Nov 29 '12 at 0:53
2
\$\begingroup\$

You may be able to bit-bang one of the interfaces through a general purpose I/O pin, leaving the special function pins for the other interface.

You might be able to gate one of the signals - particularly the clock - with something enabled by an output pin, so that it doesn't reach the chip which is not currently the target.

You could try to find peripherals which all use the same interface.

At an extreme, you can add a second micro as a slave to function as a format converter. The isn't too expensive parts wise, but it means another program to maintain, and load into each device in production.

\$\endgroup\$
  • 1
    \$\begingroup\$ Bit banging SPI is easier for me than bit-banging I2C, if you need to make that choice. \$\endgroup\$ – Scott Seidman Nov 28 '12 at 23:14
  • \$\begingroup\$ @ScottSeidman yes, that would be logical, unless the SPI needs to be utilized a lot more or at a higher clock rate. \$\endgroup\$ – Chris Stratton Nov 28 '12 at 23:32
  • 1
    \$\begingroup\$ If the SPI needed to be fast, I'd probably go out of my way to find a controller with two MSSP's, or work harder to get peripherals that used the same bus. I just don't like the idea bit banging I2C, especially when the peripheral might be clock stretching (though it shouldn't have much of a reason to if your rate is bit-bang limited) \$\endgroup\$ – Scott Seidman Nov 28 '12 at 23:36

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.