I2C vs SPI

[Electro Fan]

A few questions for anyone who has some experience or insight and who would like to share:

1. How often do you encounter (hear about, or have an opportunity to debug, or design/build projects with I2C vs. SPI?  In your experience do you see one or the other more often?

2. Do you find one or the other preferable to work with?  Why?

3. This is probably the toughest question - not an engineering question but a market/business question: does anyone have any insight on either the total size of the market (however you want to quantify that) or the relative size of the installed base for I2C and SPI?  Is one or the other dramatically greater or are they used at roughly an equal rate across the board?  Do you think one or the other is likely to become relatively more popular in the future or are they each likely to hold their own and coexist as they currently do?

4. Any other comments/thoughts regarding I2C and SPI are welcome.

Thanks!  EF

[free_electron]

1) Daily and equal share
2) I2C preferred. addressable , acknowledge form slave , collision detection, multimaster. overall more robust bus. SPI is NOT a bus (devices are not adressable)

3) I2C is more popular and has a larger usage base. IPMI ATCA adn SMbus are massive deployments of I2C. Every compute rmother board uses I2C to read memory configuration, monitor on board temperature and voltages and much more. IPMI and ATCa channel i2c over backplanes for huge telecom and computer racks. SPI is nowhere to be seen in those applications.

4) SPI is annoying because of its operation modes and nonstandardized framesizes. At least with I2c the physical layer is completely shielded from the apps layer.
the Physical layer has collision detection, bus arbitration , multimaster operation and all the other 'gunk' on board. once you got a working physical layer you don't need to worry. its all just bytes flying across. Not so with SPI. some devices use 4 bit for this , 9 bit for that. There is no standard and everybody does as hepleases. From a code and driver perspective this is a nightmare.

[nctnico]

Most of my more complicated projects have both SPI and I2C devices. When I need to select an ADC, DAC or other peripheral the last thing I look at is whether its SPI or I2C. A major disadvantage of I2C is that the high level is defined close to the supply voltage which means you run into needing a level shifter quickly if you have different voltages on your board. SPI is much more forgiving in most cases. Driving a 5V device from 3.3V SPI lines is usually not a problem. Besides that SPI is over 10 times faster in most cases so the software doesn't need to wait long until a transfer is finished.

[Neilm]

Depends on the application. I2C is very useful but can be limited. I have been on a project at work were the processor we had to use was defined and didn't support SPI. As we didn't want to bit bash, we went with I2C. The result is that the best ADC we could find is now causing issues when doing the more delicate measurements. It puts so much current out of the inputs, we have to take into account the output impedance of the preceding opamp. The SPI one we wanted to use didn't have that issue.

[Kjelt]

What I noticed (correct me if I am wrong) is that the e2proms and esp. the larger ones are mostly SPI nowadays.
RTC's , port expanders and such on the other hand seem to be almost all I2C.
I2C is more robust in my experience, SPI is mostly faster.
Warning, stay away from the I2C hardware peripherals from ST in their microcontrollers, unbelievable that they screw up such old tech standard in their micros.

[Basstudio]

Agree with the above.
From my experience I prefer to use I2C but use SPI for performance. I2C is easier for in-circuit programming.

[veryevil]

The project I'm working on at work heavily uses I2C and I would definitely avoid it in the future for must things. The software complexity and complicated debugging of the shared line made it painful to work with.

I would only use I2C now if I needed the addressing that you dont have in SPI and even then if I could get away with it I might consider a shift register to CS line arrangement.

The fact that the software requires  a state machine to drive it and the complication of the interrupt routine / driver code makes it unnecessarily complicated.

Also without a scope that has I2C decoding it is a pain bit counting and working out which device has the data line. Its also much slower than SPI.

[Harvs]

Warning, stay away from the I2C hardware peripherals from ST in their microcontrollers, unbelievable that they screw up such old tech standard in their micros.

Care to elaborate?  I've used in the cortex M0 and M4F parts without issue talking to microchip ADCs.  Albeit an I2C ADC is about the most benign use of the bus.

[Kjelt]

Care to elaborate?  I've used in the cortex M0 and M4F parts without issue talking to microchip ADCs.  Albeit an I2C ADC is about the most benign use of the bus.

The baddest is the STM8 hw i2c implementation, ST has an errata sheet and say there not fixing anyof the  Known issues you have to handle a workaround in software. The demo code in the AN they supply s*cks big time, try it
On the Arm32 platform the guy from ST that gave the training told us literally they had so many problems with customer implementations and questions that they wrote their own code from scratch it is called something like ICPal (look on their website) and he told us not to bother writing our own code since that wold be aguarantee for failure since there are many states on the I2C bus that are not correctly handled by the hardware and need work arounds in the sw. I find that pretty awfull knowing how old the I2C spec is. Too bad cause ST micros and the company are really decent for the rest.

[Harvs]

I see, I have only used their peripheral libraries which if there are software workarounds it would be buried in those libraries.

My problem with the implementation is there doesn't seem to be a good way to use the DMA.  Possibly that's just the reality of using an I2C bus, but it's a fairly painful penalty on the processor to have to manage all the transaction details on a 1ksps 16bit I2C ADC.