To SPI or to I2C...that is the question.
To SPI or to I2C...that is the question.
(OP)
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
If this topic has already been dealt with in a previous post could you direct me to it.
Thanks





RE: To SPI or to I2C...that is the question.
RE: To SPI or to I2C...that is the question.
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.
RE: To SPI or to I2C...that is the question.
RE: To SPI or to I2C...that is the question.
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
RE: To SPI or to I2C...that is the question.
http://www.maxim-ic.com/appnotes10.cfm/ac_pk/10
http://www.maxim-ic.com/appnotes.cfm/appnote_number/1131/ln/en
for comparisons
RE: To SPI or to I2C...that is the question.
Brennaj
RE: To SPI or to I2C...that is the question.
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.
RE: To SPI or to I2C...that is the question.