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