To SPI or to I2C...that is the question.

[brennaj]

I am trying to decide which serial standard to use in a data acquisition and diagnostic system I am working on. I can buy IC's with either interface to do the job. Any suggestions or comments based on your own experience would be helpful.

If this topic has already been dealt with in a previous post could you direct me to it.

Thanks

 

[felixc]

No one really betters the other. They are just two specs that were established by competitors. They became defacto standards, because others joined them instead of defining yet other buses. I2C is from Philips, and SPI is from Motorola. Or Europe vs US, some might say. The goal of both was to reduce the number interconnect pins between consumer ICs for low-speed, episodic purposes, such as tuner and volume controls in a TV set, thus lowering the costs. Sun defined a higher-end version of I2C, the ACCESS-bus. None are really "standards" in the sense that not all parts that pretend to have one interface can interact with every other part that has the same interface. They electrically connect, but there is no such thing as "plug-and-play" with these parts. Hope this helps.

 

[brennaj]

Thanks Felixc,

I guess the question I should have asked with respect to SPI and I2C was which one (if any) you prefer to use and why.

 

[felixc]

I see much more push for the I2C standard than the SPI. I would favor I2C. I just saw an ad for I2C repeaters from Philips. That means expandability, which may be interesting for you.

 

[Foxfur]

I2C is a nice way to go, unless all devices that you need to communicate with do not have it. In that case, SPI is the winner as bit-banging will get you there. SPI is a simpler convention as it has just shift registers and a clock. I2C is somewhat (may be an understatement) overly complex. Heck, philips new CD-R drives don't even use it anymore.
Another problem is that I2C is patented, meaning you must obtain a license from Philips if you intend to market your design (this was true as of a few years ago, I believe it still is so). Not so with SPI. The nice thing about SPI is that you , if you're good with PLD's or FPGA's, you can roll your own custom SPI solutions. I have not reached that level of conciousness yet, but soon perhaps.
Also if you plan a multi-master system, steer clear of I2C, it WILL be messy.
I2C can hog the CPU, mainly in a MM system though.
All of this is not to say that I2C is complete crap. It certainly is not. It can be a bit more difficult than you think. If there is an option besides I2C, take it.
The main attraction to SPI, for me anyhow, is the roll your own possibilities, like using a couple of 8-bit universal 3 state SR's to make a 16-bit I/O port.
I'll sum it up by saying, "SPI won't make you cry".
I hope you all don't think I'm a wack with venom dripping from my fangs getting all worked up about I2C. I just needed to vent, that's all!
Don't base your project on my opinions presented here, be sure to do some research as well. Sometimes I'm wrong, and may even be wrong (or wrong-headed) in this case .
Have fun,
Foxfur

 

[jbartos]

Suggestion: Visit

http://www.maxim-ic.com/appnotes10.cfm/ac_pk/10

http://www.maxim-ic.com/appnotes.cfm/appnote_number/1131/ln/en

for comparisons

 

[brennaj]

Thanks to all for the information. It's exactly what I was looking for.

Brennaj

 

[47gandalf]

Here's my 2 cents worth too. I've used both interfaces and nowadays there is not much issue with speed difference. Both have a master/slave organization, with the peripheral devices usually being slaves.

One key difference I've seen is that it is easier to add devices to a I2C bus than SPI because the new device's address matching is in software for I2C. In SPI you have a *SS (not-Slave Select) pin to drive so the device knows you're talking to it. This means you need to have left a pin for each device available from your host MCU or a decoder (like '138). So I like I2C when the system might have modules that are not always present. You can poll the bus with a broadcast message at boot time and see who responds to determine which drivers you'll need.

Also, SPI is full duplex, since it has both MISO (master-in, slave-out) and MOSI (master-out, slave-in) pins. (I like the Motorola names for these; easy to remember which way the data is going.) So a byte is passed in each direction when the clock signal operates.

So I2C has only 2 wires while SPI needs MOSI, MISO, SCLK, and a *SS for each device, or a code to generate one.

Don't forget that I2C was designed for communication between ICs on the *same board*. It is not meant to be driven off board so common devices can't handle a very long run or heavily capacitive loading.

If you need to be the master, or have multiple masters, both are a lot more complicated than if not. I rely mostly on the MCU having a dedicated hardware subsystem that can handle the master role.

 

[brennaj]

Thanks again for all the helpful info.