OK - So how do you share SPI and I2C devices on a PICAXE ?

srnet

Senior Member
Normally you cant directly mix a SPI and a I2C device on the same PIC Master Synchronous port. There is a risk that the activity on the SPI port will trigger an operation in a I2C device.

The 28X2 and 40X2 native PICs do have two such ports but the PICAXE only makes one available.

So if you are using the SPI port for a device already (on a PICAXE) how do you safely connect a I2C device on the same port ?

Do you 'just' need to turn off the I2C clock line into the iddle state such that the SPI device runs as normal, and the I2C device does not see the clock. Then when you want to access the I2C device, turn off the SPI device via its select pin, and turn on the I2C clock.

A soloution needs to be real small in board space terms, a SOT device or similar.

Analogue switch in the clock line, mini SOT logic AND gate, anyone tried these options ?
 

hippy

Technical Support
Staff member
The 28X2 and 40X2 native PICs do have two such ports but the PICAXE only makes one available.
You could try accessing and using the 'hidden' second MSSP peripheral as SPI via PEEKSFR and POKESFR. I haven't tried but it looks possible. One trick is to use HSPISETUP, PEEKSFR relevant registers, then you know what to put into the other set.

I think multiplexing SPI and I2C on the same bus is technically possible but I recall it's quite complicated because of the shared I2C SDA / SPI SDI and shared I2C SCK / SPI CLK pins. I'd try using the second MSSP or bit-banging SPI on other pins and there's the SHIFTIN and SHIFTOUT to simplify that.
 

srnet

Senior Member
You could try accessing and using the 'hidden' second MSSP peripheral as SPI via PEEKSFR and POKESFR. I haven't tried but it looks possible
Good point, I now recall someone posting about this in the last month or so, a search is needed.

There are harware solutions apparently, you need to look for I2C bus extenders\isolators. Several devices from NXP that allow you to extend or isolate sections of an I2C bus, the PCA9507 for instance, its in a 8pin SOIC or TSSOP package.
 

hippy

Technical Support
Staff member
I'm not sure I2C bus extenders help a lot as they will still need their I2C SDA line isolating and I2C SCK kept inactive. One could use a diode to make the SPI input to the PICAXE also open-collector which could solve the issue of PICAXE SDA / SDI sharing.

Given the choice of adding any extra components or using other I/O pins, I'd opt for the later when possible. Simpler circuitry, simpler software, more likely to work first time.
 

srnet

Senior Member
Well, what does work is using a simple analogue switch to 'turn off ' the SDA and SCK lines (used by the SPI also) between the PICAXE and an I2C device.

I used a DG2743 as its available from Farnell. The NXP bus isolators were not stocked by Farnell, and I will try a more readily available analogue switch at a later date.

I have had a program running for a couple of hours that does 30 or 40 SPI writes to a RFM42 device, does about 150 reads, turns on the I2C bus and then does a read from an RTC. The I2C pullup resistors are on the I2C side. The time is read from the RTC about once every 4 seconds.

Scope trace shows the CLK line before and after the analogue switch. Not saying which is which.

Now, to access the SPI device you need to do the hspisetup every time you want to use an SPI device and a hi2csetup every time you want to use a I2C device. Anyone forsee problems doing this all the time ?
 

Attachments

hippy

Technical Support
Staff member
Well, what does work is using a simple analogue switch to 'turn off ' the SDA and SCK lines (used by the SPI also) between the PICAXE and an I2C device.
What might be best is to post the full circuit of how you have the SPI and I2C interfacing and isolating done so we can look to see if there are any potential problems. Particularly are you isolating only I2C or also SPI buses ?

There shouldn't be any problem with alternating between HI2CSETUP and HSPISETUP though it might be best to explicitly 'OFF' what's on before setting-up the other. You would have to experiment to see what's actually necessary.

One thing you may have to consider is possible I/O pin glitches as the internal hardware switches from one mode to another but the isolation circuit should prevent any of those affecting the actual SPI and I2C devices leaving it just a matter of isolating, changing, de-isolating in software.
 

hippy

Technical Support
Staff member
Thanks.

My main concern would be what the RFM42 does with its SDO when it's not selected; does it tri-state or idle low or high ? If tri-stated it seems there should be no problem, if low it will prevent I2C from working, if high you could damage the RFM42, PICAXE or the I2C device when +V shorts to 0V during I2C comms.

It seems SDO is sort of tri-stated - "When nSEL goes high the SDO output pin will be pulled high by internal pullup" - but SDO can also be used for other signalling when nSEL is high; see 'trclk[1:0]' and 'itsdo' configuration bits. Assuming those bits were never asserted it may be okay but the circuit might not guarantee electrical safety. It depends how the RFM42 controls SDO when nSEL is high. I'd guess open-collector so it is safe but couldn't find that in the datasheet.
 

srnet

Senior Member
I was aware that the RFM42 SDO pin can be selected used for other things, and these options are not used.

Cant see how driving the SDO line with another devices (the I2C device) would be a problem, other devices driving the SDO line is the normal situation for an SPI bus.
 

srnet

Senior Member
The isolation even works with a humble 4066, although the clock waveform is not so clean, on both the input and output. I guess the older technology 4066 is not so happy at 3.3V.
 

fernando_g

Senior Member
The 10k I2C pullups are rule-of-thumb value for 5V. If you are operating your circuitry at 3V3, I would reduce the pullups to 6k8, and your waveforms would look healthier.

Although not absolutely necessarry, f you want to use a 4066 type switch, use the 74HC4066 version instead of a generic one. They have much improved characteristics at 3V3 operation.
 

beb101

Senior Member
This concerns sharing the SPI/I2C bus on a Picaxe 20X2. I found questions on this issue in the Microchip Forum (Post 4),

http://www.microchip.com/forums/tm.aspx?m=149624

which presented the attached image as a solution. And later in another thread, the poster
answered a similar question with this reply, quote,

"Since this post, I made a card with such Mosfet, and I confirm It really works
(SPI & 1MHz I2C). I think It's better to isolate both SDA & SCL (use 2 Mosfet) if you can.
But manual SPI is enough if you don't wan't very high SPI data rate.
Another idea would be to disable I2C slave by shuting-down its power. But it's a bad
idea because of ESD diodes that will keep the lines low."

So, seeking a second opinion, will this work and is a 2N7000 satisfactory for the mosfet?

Baxter
 

Attachments

westaust55

Moderator
I cannot Guarantee the method will work but it will not harm the chips so be brave give the concept a try.

I have used 2N7000 FETs in the two i2c bus lines for level shifting successfully and your schematic as per the link you gave it very similar.
Two recommendations:
1. Add a second FET in the clock line so extraneous 1's as possible start and stop bits on the i2c bus are not seen by i2c slave devices, and
2. Add pull up resistors on the PICAXE side of the FETs - this is what Philips/NXP recommend with level shifting FET circuits.

So give it a try - on a breadboard first
 
Last edited:

beb101

Senior Member
I am intimidated by MOSFET parts. I was going to use a pair of BSS138s, but I couldn't figure out what pullup resistors to use on the Picaxe side. So, I took the easy way out and decided to use a 74LVC2G66 with the control inputs connected. A low SPI /CS will turn the switches off and high /CS will turn them on. The consensus seems to be that a 4066 will work just fine.
Baxter
 
Top