John, you said sharing the bus is possible if you make sure a transition on the sda/sci pin only occurs while scl/sck (they are shared to) is low. I've had a look at the data sheet and there a different clock options, change on rising/falling edge, if I have it on the falling edge would this avoid messing up any I2C stuff while using the mssp module for both?

Well.. I said probably... that subtle but real difference between not being able to think of any significant problems on the surface but then drilling down into the data sheets to find that there are things you didn't think of..

But, looking at the SSP waveforms in Fig 25-6, it sure looks like setting CKP=0 and CKE 0 or 1 (depending on what your SPI slave wants) would not mess with I2C by generating false Start/stoP conditions.

One thing that WON'T work is using the standard hookup for the SPI. Since the I2C SDA is shared with SDI, reading the SPI device will cause unwanted transitions on SDA with SCL=1, generating false, SPI data-dependent Start/stoP conditions. The figure shows the problem i.e. for either SMP value, SDI (SDA) changes when the clock is high. Fun! Its not a show stopper since you propose to bit bang the SPI and can reassign pin functions. I think just interchanging SDO and SDI functions for the SPI may do it but sketch it out to be sure.

To recap, what you can't have on SCL/SDA is SDA changing when SCL is 1, that generates the Start/stoP conditions you need to avoid when using the bus in SPI.

You shouldn't have problems with the pullups. The PIC outputs are more than capable of driving them.

The firmware should have specific setup routines for each of the bus configurations and a common release routine that puts the bus in a benign state (SCL=SDA=1 in a sequence that does not generate Start/stoP, turn I2C master OFF, deselect the SPI slave etc.). The setup routine for each would carefully configure the MSSP, IO etc for the intended use, I2C or SPI, without going through any problem conditions.

This is the kind of thing I would do very early in the project. Do the I2C first (with no SPI hooked up) then the SPI (with no I2C) then write test code that reads/writes to all slaves lots and indicates any errors.

Have fun!

 

One thing that may help here is the SPI needs a chip select line, and that line could arbitrate a blocking gate on the I2C bus: when the SPI CS is enabled the I2C bus is disabled.

*HOW* to disable the I2C is not something I have on the top of my head... but it doesn't seem impossible.