which protocoal would you prefer ?

[Doctorandus_P]

I do not have a real preference.

SPI is a lot simpler then I2C, but I2C can do extremely much with just two wires.

SPI can also reach much higher clock speeds and data transfer (expecially quad SPI).
An SPI bus is also easy to isolate with opto couplers.

However, if you want to control some 10+ (low speed) IC's in a project, then SPI becomes difficult.

Most microcontrollers have peripherals for both.
Because of it's simplicity, SPI is easy to learn and I would certainly start there.
You just need to read the datasheet, and set a few bits in some registers.

I2C is al lot more difficult to master. There are quite a few exception states (clock stretching, repeated starts, multi bus master (seldom used).
For I2c I hope you can get a decently written library for your microcontroller to start with.

For I2C, also have a look at SMBus. (System Management Bus). It is a slightly modified I2C. One of the significant changes is that it has better defined timing and also implements timeouts and recovery from bus faults.

[Berni]

Getting a lot of devices on a I2C bus can be difficult in practice however.

For throwing a bunch of different sensors onto a bus it works nicely since they are all different chips with different addresses. Sometimes you do get addresses colliding, but in most cases you can convince one of those conflicting devices to move to a different address. However when you want to have something like 10 identical ADC chips on a bus you run into problems. Most chips are able to be set for 1 alternative address, a lot can do 3 alternative addresses, rare ones can even do 7, but i don't think i seen more than that. So in a lot of cases getting more than 2 of the same chip on the bus is not so easy. As a result you need to have multiple I2C buses or a mux chip.

SPI does not have this problem, but admittedly does get a bit annoying by the time you have 10 chip select lines. You can use a BCD to decimal chip from the standard 74xx logic series to get that down to 4 lines, or a shift register to get it down to 3. However quite a few simpler SPI chips support daisy chaining by feeding the MISO of one chip into the MOSI of the next. Then the SPI master simply makes one really long SPI transaction and data gets distributed to all the chips by shifting it trough. This works really well for DMA too.

All depends on how well designed the chip is. I seen them range from beautifully simple "just clock it and get data out" to horrendously complicated messes of registers that work in the most annoying way possible.

[mikerj]

If I have a choice I avoid I2C, there are several potential traps to fall down.  One really annoying thing is that unlike SPI with it's symmetrical drive it's difficult to control the slew rate on the falling edge of the I2C data/clock signals. When you have sensitive analog signals nearby (or even on the same IC) controlling slew rate is important to reduce crosstalk.

Another common issue is that's it's possible to get into a situation where a slave is holding data low preventing a stop or start being asserted (e.g. micro gets reset part way through a transaction), and you have to resort to bit bashing clock cycles out to get it to release the pin.  SPI uses more pins (which can make it a non-starter in some applications), but it's simpler to implement, much faster and more reliable IME.

[Sal Ammoniac]

All depends on how well designed the chip is. I seen them range from beautifully simple "just clock it and get data out" to horrendously complicated messes of registers that work in the most annoying way possible.

This applies in spades to MCU I2C implementations. Some offer minimalistic support for drivers with the drivers having to control sequencing though every single state during a bus transaction. Others handle most of the state transitions automatically and driver code only needs to handle exceptions. Some require complex calculations to set the bit timing while others make it simple.

My current favorite implementation is on the STM32F7 and H7 parts. Most of the work is done by the peripheral and it’s very robust with few quirks common to other implementations.

[Renate]

Clock stretching in I²C is a demonstrated phenomenom when the devices are travelling at relativistic speeds.

Sensors? Give me I²C so they can be attached or detached and I know what's going on.
Color LCD display? Give me SPI because I need the speed.
I also use 40 bit SPI on Analog Devices AD9850 DDS synthesizer (but I have to bop the chip select myself).

Oh, yeah, if you do AVR with AtmelICE, you can use the DGI Gateway for a debug "serial" interface over SPI (the same one you used to program).
It's more convenient than using the UART pins, especially if you need them for something else.

[Siwastaja]

My current favorite implementation is on the STM32F7 and H7 parts. Most of the work is done by the peripheral and it’s very robust with few quirks common to other implementations.

Yes, they FINALLY spent the (rather manageable) effort to actually design the I2C peripheral they are advertising. With the F7/H7 families, it also became actually possible to use DMA for I2C.

Earlier STM32 MCUs claim to have "I2C" but what it really is, is just a stupid generator of a few simple IO patterns needed to implement I2C, but you still need to do half of the hard work in software. Now create start condition! Is start condition produced? Now clock bits! Are the bits out? Now create stop condition! A single transaction required many interrupts close to each other, and oh boy the possible number of different fault conditions, I remember spending a whole week if not more to write reliable I2C communication in STM32F2 series.

Many MCUs are/were similar. Lazy MCU peripheral designers, nothing else.

Also the recovery sequence sucks, and the fact that even that isn't necessarily enough. I have heard about designers who simply routinely add a high-side power switch on every I2C IC so they can reset them and retry communication.

Now, of course it is also possible to colossally fail an SPI slave device so that it does not reset the communication state on high level of nCS. It's just that I have never seen or heard about one. It's quite easy to get right.

[Doctorandus_P]

If you want t have a lot of identical IC's on an I2C bus, then you have a bunch of options.

If your Chip has an adress line that can be toggled to change the I2C address, then you can use an I2C I/O expander to toggle the address lines. So set them all low, except for the chip you want to talk to at some time. With a Demux such as an 74HC138 you can also build further upon this idea.

There are also I2C switches, which can branch off an I2C bus, and thus create extra address space.

And of course, a lot of uC's have multiple I2C buses. It's also quite common that I2C I/O lines can have "alternate positions" on your uC, and you can also use this to add more "virtual" I2C buses to your uC.

With all those switches you may run out of bandwidth (Especially if you have to switch the switches via I2C too) So plan ahead.

[Berni]

Not all I2C chip address select pins can be toggled on the fly. Some only check them on power up, especially the ones that have some special extra combinations to squeeze more address options in (like high/float/low or connecting some other pins together, or pullup resistor value etc.). Certainly a neat trick for the ones that do work with it.

Tho my usual fix for address collisions is adding an extra I2C bus since modern MCUs often have 3 separate I2C controllers. This also helps increase the bandwidth of this molasses slow bus.

But I2C is still an excellent bus for simple things that don't need performance like temperature sensors or slow ADC/DACs that only get updated a few times per second. As long as you have a smart I2C driver that can do things in the background (waiting for a I2C transfer to finish can eat a lot of CPU time due to how slow the bus is)

[mariush]

Besides the added complexity is there a reason why USB isn't used more often instead of i2c or spi?

For example, a 1 wire temperature sensor could easily work as a usb 1.1 device, 1.5 mbps or 10mbs is plenty fast

Same for an adc or a led driver or display controller ...

Well i guess the polling rate of 125/1000 Hz could be an issue for devices that have to interrupt faster than 1ms but other than that...

[hans]

Because I2C and SPI are mostly just a standardized way of shifting bytes in/out of serial devices. Sure I2C has some addressing and multi-master bus arbitration , but other than there is nothing to it.

USB has a whole protocol: multiple tokens, endpoints, device descriptors, setup state machines, and multiple protocol classes and host/client drivers.
In addition, each USB device needs an unique VID/PID pair to identify itself. These need to be unique to avoid driver conflicts. The USB association manages, *cough* sells VID/PID ranges for customers to use. For companies making many USB products this is a small fee to pay, but anyone else starting it's very expensive.

The "standardized" USB protocol for attached equipment is probably something like CDC-ACM, e.g. a serial port, just like the old days where everyone used RS232 to hook things up together/to PCs.

[Berni]

USB has too much complexity indeed.

But the other reason is that USB requires an accurate clock signal to send data at the correct bitrate. This means that a lot of USB chips also have a crystal next to them, or they use extra trickery in that they calibrate there own internal oscillator against the data being received, so it might garble some of the first transmissions.

This is some of the same reason why UART is pretty rarely used for communication between chips. You do see it used when talking to modules (like GPS, bluetooth etc..) but there the module contains a full on MCU (with usually again a crystal). You never see UART in things like temperature sensors, ADCs, DACs, IO Expanders...etc Since using I2C or SPI the clock is provided by a dedicated clock wire, removing any timing issues since slave and master both run from the same clock signal.

In fact SPI is so simple that you can directly connect a jelly bean 74HC595 shift register directly to a SPI bus and it will work like a IO expander. Any data bits you clock in will appear on the shift register outputs at the end of the SPI transfer. So this shows that it takes only 1 shift register chip to create a valid SPI Slave device.

[DavidAlfa]

[Renate]

In addition, each USB device needs an unique VID/PID pair to identify itself.

Also, they need a unique serial string. Even in a one-off device, give it one, even if it's "1".
Especially in Windows it makes a big difference swapping ports.

Yeah, the USB-IF controls the numbers. Maybe they should have made them like A, B, C, D IP numbers.
And yes, USB (especially host) is a lot more complicated than I²C.

[Siwastaja]

As this thread shows, even just I2C is on the bad end of the complexity spectrum embedded developers want to deal with (with clock stretching, multimaster and poorly specified error recovery that led to modifications like PMbus/SMbus). We deal with I2C fine, but USB is orders of magnitude more complex, so obviously no-go.

People like me see deterministic timing as a real value; not only for hard realtime, but as a simplification, too.

[brucehoult]

But I2C can reach out to a mile:

https://www.abcelectronique.com/forum/attachment.php?attachmentid=29845

The data rate is pretty low but it apparently works.

That is a pretty impressive distance for I2C. Even if it is only 1.5KHz clock speed

But yes SPI would go an even longer distance if it is properly terminated. Only real limitation there is the round trip delay. Doing the math this works out to about 70Khz max clock speed. Tho it needs more wires so not as practical. The actual correct protocol for these distances is RS485 anyway, as it is designed to actually work over a mile long cable and designed to handle noise that is inevitably picked up in a real use case. Given a good enough cable it can likely do 1Mbit over that mile.

Back 35 years ago Apple computers had networking that used their serial ports (RS-422 from a Zilog Z8530 SCC chip) with external passive components (mostly a transformer) to do CDMA at 230.4 kbps up to 100m on shielded twisted pair. A 3rd party, Farallon provided an alternative passive external box (again, mostly a transformer) driving unshielded twisted pair that extended the range to 1 km / 3000 ft.

Farallon also supported a 1 Mbps mode, but I don't recall now what the range of that was.

[westfw]

USB has too much complexity indeed.

In addition to the complexities already mentioned, USB is also highly asymmetric, with the "host" side being much more complicated than the (already complex) "device" side.  Many microcontrollers ONLY implement the "device" side.

Back 35 years ago Apple computers had networking that used their serial ports (RS-422 from a Zilog Z8530 SCC chip)...

Unfortunately (?) that design pretty much ONLY worked with that particular Zilog chip, meaning anyone that wanted to implement localTalk had to use that exact chip.  Which ended up not being very popular, and it slowed the adoption of Ethernet on Macs :-(

[brucehoult]

Unfortunately (?) that design pretty much ONLY worked with that particular Zilog chip, meaning anyone that wanted to implement localTalk had to use that exact chip.  Which ended up not being very popular, and it slowed the adoption of Ethernet on Macs :-(

Quite justifiably so, I'd say, as a PhoneNet adaptor was I think something like $25 while ThinNet and early 10baseT cards were hundreds of dollars. 230.4 kbps was faster than most people's internet connections until into the 2000's (I had 128k/128k DSL until 2004), so was just fine for distributing internet around the home for a long time. 10baseT was decently cheap by ... 1998 ? .. or so, but not really a huge advantage at that point unless you were using a centralised file server.