Dilemna - i2c or SPI...

A

Adamey

Senior Member
I have successfully connected several X2 chips together and used i2c to transfer data back and forth from my master to three slaves. Everything works great and having the built-in i2c support has made coding this extremely easy.

I was looking at a few devices I wanted to connect and there's a couple I REALLY want to use, but they are SPI only. I figure no problem, X2 supports SPI. Then I see that the same pins are used for i2c and SPI meaning I can't run both on one chip. So my choices seem to be:

- Stick with the i2c to connect the PICAXE's together and make something up to handle SPI (like maybe a UART-SPI convertor).
- Use SPI on my remote PICAXE's to connect to other devices and come up with a method of sharing data between my master/slaves instead of i2c.

Neither one seems like it'll be fun to try and replace.
 
G

Grogster

Senior Member
This might not suit your application, but you could setup an X2 chip to act as a controller for the SPI device, along with another chip such as the 18M2 which acts as an I2C buffer processor thing.

What you do then, is have the 18M2 talk on your I2C bus, and convey information via serial commands to the X2 chip which then talks to the SPI device. This assumes that your SPI device is on a physically seperate PCB to your main PCB.

Not exactly pretty, and probably better ways to do it, but that would act as an I2C to SPI translator. If you use the hardware serial port, speeds of 9600 baud between the X2 SPI controller and the 18M2 I2C controller should be possible.

How much data do you need to transfer between the SPI device, and how fast?

My idea may not work if you need to transfer lots of data...

If both the I2C bus and the SPI device are on the same PCB as all the other I2C devices, I would set it up with your I2C devices on the I2C bus, and an X2 part acting as an SPI controller, commanded from the main chip via the hardware serial port.
 
Last edited:
T

tjetson

Senior Member
I'm not too familiar with SPI, but as I understand it there is usually a Chip Select pin on SPI devices, that is used to grab the attention of the chip. When you want to use I2C comms, you can simply pull all of the CS pins high/low, whichever it is, and all of the SPI chips will disregard the I2C comms.
 
B

BCJKiwi

Senior Member
The other potential issue with spi is that a PICAXE pin is need for each chip to assert it's chip select - you will need to check that there are enough outputs available on your PICAXE.
 
A

Adamey

Senior Member
tjetson I was wondering about that. I think I just figured out how to do it.

My three remote X2's are on separate PCB's and are several feet away. I use an i2c extender (as suggested in another thread) to allow reliable communications over these distances. I suppose I could add an extra data line that I can pull high or low and send it to my three remotes.

If I pull the line high, then the remote X2's will configure themselves for i2c comms. If I pull the line low, then they configure themselves for SPI comms. Immediately after setting up for SPI, they would need handle all their necessary comms to my SPI devices (reading data, sending outputs).

I suppose I could time how long it takes all my SPI comms to complete, add some time on for good measure, and make sure my master doesn't pull my line high to switch back to i2c until my remotes have finished dealing with their SPI stuff.

I'm not sure how my i2c extender would like having SPI data on its lines, so I might need to also disable the i2c extender on my remotes when SPI comms are taking place.

BCJKiwi. That is the exact reason I want to use SPI. There are some high side driver chips I want to use that have multiple outputs controlled by SPI. This is what saves me on my pin count. I can control 16 devices with only 7 pins, and have things like current feedback and status on each one. Other drivers I looked at required two pins per output - one pin to turn the output on and another pin for feedback/status.
 
I

inglewoodpete

Senior Member
Adam,

Only the hSPIOut is forced to use dedicated pins.

You seem to be overlooking the SPIOut command. It can use (practically) any pin.
 
A

Adamey

Senior Member
^ I just looked in my PICAXE Manual 2 and I see no spiout command. I thought I had a current version, but is there something I'm missing?
 
W

westaust55

Moderator
Furthermore if you have an X1 or X2 part then the Shiftout and Shifting commands are unbuilt otherwise use the routines at the bottom of the mentioned pages
 
I

inglewoodpete

Senior Member
westaust55 said:
Furthermore if you have an X1 or X2 part then the Shiftout and Shifting commands are unbuilt otherwise use the routines at the bottom of the mentioned pages
Click to expand...
"Furthermore if you have an X1 or X2 part then the Shiftout and ShiftIn commands are inbuilt otherwise use the routines at the bottom of the mentioned pages."

I think that improves the accuracy:)
 
You must log in or register to reply here.
Top