SPI and I2C

Forum 2005-2010 (read only) Hardware Interfacing
1

Hello

I have read multiple posts on SPI and I2C however have a few questions which I hope someone can answer. If I have stated anything incorrectly, can someone please correct me.

I am currently working on a project where I need a few Arduino processors to talk to each other. They are not all the same processors, however that shouldnt matter.

The aim is to have the Master Arduino address up to 8 slave Arduino's or devices on the communications backbone, so whether they are arduino compatible processors or if they are IO Expanders for example.

I have been tossing up whether I should be using SPI or I2C as the 'backbone' for the comms.
From what I understand, SPI isnt fully 'supported' in Arduino yet. It works, but its not really native so to speak, and is done via bingbanging?

I2C is fully supported from what I can tell, however it is slower than SPI, but does only use 2 wires.

Is SPI, in its current form, faster than I2C, given the fact that its not really 'supported', or is I2C actually faster with how its currently implemented in Arduino ?
What determines the speed also, as I see there are a few different speed options when reading wikis about these comms. Are these settable somehow or is it a case of the bus going at the speed of the slowest device?

Also can a number of different devices all go on the same bus if they all talk I2C or SPI, or is there some variation between implementation of these between brands so its not all smooth sailing?

Along with the master Arduino talking to a number of slave Arduino's, I want to be able to talk to other SPI and I2C devices, such as SHT15's and SCH1000's and I2C EEPROM etc. I am just a little unsure what is the best method and if I can also implement hardware and software version of SPI or I2C at the same time.

To break up what I just said:
The SHT15 I have isnt SPI or I2C, so isnt really an issue for this now that I have written it...
The SCH1000 is SPI. If I was to have the hardware pins of the master Arduino go to the SPI backbone, is there a way for me to implement software SPI on different pins for the SCH1000 so it doesnt take up an address on the SPI backbone? Basically so I can have 8 addresses for other devices on the backbone.
The EEPROM I have is I2C. If I was to use an I2C backbone instead of SPI, can I implement a software I2C for the same reasons as above, to provide the 8 addresses on the backbone still without this EEPROM taking up one of the addresses?

From what I have seen, I2C looks easier to implement nicely, however I am just unsure about the speed factor and if SPI is actually the better way to go for being a communications backbone, given the current way these comms are implemented in the Arduino IDE.

Is version 19 of the IDE improving support for SPI by the way?

Thanks in advance

James

2

A lot of questions.
Last first: Yes there is a Hardware SPI now in Arduino 19!

Now for the speed: I2C is 400k BPS at max, and you would rarely need more for a processor of the Arduino class. If you seem to have that requirement I am interested to learn this!

SPI can (!) be considerably faster.

I2C is a very mature protocol, and you can have more than 100 devices on the bus, but you never will, for "electrical" reasons...

SPI needs 4 lines, but I2C needs also 3 lines! The main difference is, that addressing a device is part of the I2C protocoll, whereas you might need additional chip select lines for SPI!

And there is rarely THE SPI, in many cases it is a kind of SPI, you have to adapt to....

SPI is fine for point-to-point connection to a fast device, as a high speed 12 bit ADC, an Ethernet chip, or SD cards....

Software SPI is fine, but you loose all the advantages of high speed.

To connect 8 processors I should strongly recommend I2C

3

Thanks very much deSilva.

Ok, based on what you said about a kind of SPI, rather than The SPI, then that is good to know.

The sort of comms I will be having will simply be commands for the slaves to do, or commands to report the status of inputs or something, and the slaves replying back with a confimation or a value etc. So my intension at this stage is just for a simple poll. Ask the slave for info, slave replies - move onto the next slave. Or tell the slave to set output 2 and 3, and slave replies back with confirmation.

I2C sounds easier to implement and nicer when dealing with more devices, as the number of pins seems to be fixed.

What I see on the I2C EEPROM I have, is 3 pins for address. I assuming that a device like this is only addressable in this region, whereas another arduino processor could be addressed outside this range in sofware. ie if I have 4 EEPROM chips, they will need to all be addresses in the 0 to 7 range, however if I have 5 Arduino slaves, then they could be like address 23, address 56 etc... is that a correct assumption?

If I2C is maxed at 400BPS, how is this set? ie if I was to only have arduinos on the bus, how do I set the speed?
If I was to have arduino's and EEPROM's on the bus, is the speed going to be the same, or may it have to change to cater for the EEPROM (if it is slower that is).

In regards to SPI and Software SPI - I realise I would loose the speed factor, however the function I would have for the software SPI devices wouldnt need to be fast. They would be checked maybe once a minute, so wouldnt be an issue if they were slow. The questions was more around, can I have Hardware SPI and software SPI implemented in the same piece of code and completely seperate from each other?

This has cleared alot of things up for me though, thank you

James

4

SPI and I2C (and HardwareSerial) are completely separated and independent. They all have their specific unalterable pins...

Nearly all devices are able to work at 400 BPS. The master sets the clock speed, but the slaves can "stretch" this if they cannot keep up. However I am not aware of such slow chips... It seems to be a historic concept... I2C is very old...

The 3 address pins (some devices have only two or one!) are only part of the address. There is an additional fixed 4 bit part specific for the chip. So you can have 8 different chips of the same kind at one bus. Many chips are produced with two different addresses (the second version called ....A, this is not a better chip, but just one with an alternative address in it) Processors can of cause choose their own address out of 127.

5

SPI and I2C (and HardwareSerial) are completely separated and independent.

Indeed - Im not sure where I said something to negate this... I am not using HardwareSerial for any backbone comms...

I was eluding to using SPI hardware pins MISO, MOSI, SCK for the backbone, but then using seperate general IO pins at the same time to implement a software version of SPI at the same time, to have a seperate comms network basically... whether or not this is possible I dont know.

If I go down the I2C backbone path then I wont need the software SPI implementation anyway, and it looks like I will go down the I2C backbone path from what you have said.

The 3 address pins (some devices have only two or one!) are only part of the address. There is an additional fixed 4 bit part specific for the chip. So you can have 8 different chips of the same kind at one bus. Many chips are produced with two different addresses (the second version called ....A, this is not a better chip, but just one with an alternative address in it) Processors can of cause choose their own address out of 127.

Ahh - very good. I was not aware of this. That is very good news.

Thank you :slight_smile: