A nice advantage of SPI is that it can not lock up the master.
This is not true of I2C, where the slave could stretch the clock forever.
This is also not true of UART, where the slave just might not respond. But in fact both SPI and I2C can be simpler than UART since they are strictly master/slave. With a UART, the slave could send you unrequested data, which means your software has to handle asynchronous events. Even if it doesn't you probably have to implement timeouts and input flushing.
SPI is simpler than I2C in that it is a single-master bus, so accesses are atomic (at least at the bus level, within your RTOS is another story...).
You can use simple logic gates as SPI peripherals: for example, 74HC595 works as a SPI accessible 8-bit output port. This is important because such chips are the cheapest available (vs. I2C output port or UART to parallel..)
Despite all this simplicity, SPI is very fast.
Where UART has the advantage is software: picocom on Linux or Teraterm on Windows. Basically you don't have to develop any host-side software if you use a UART. I like to use the old ymodem protocol for embedded system firmware updates.. since again no host-side software has to be developed.
UART has another advantage, fungible cheap very-long runs when paired to balanced RS485 transceivers–at least, for relatively slow baud rates, and with decent shielded cable, you can get 56 kbps well over a kilometer. Better with some effort.
In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product).
I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...
OMG, I2C is... terrible, as others have commented, because a slave can hold up the bus 'forever'. Also, not frequently understood is the crappy protocol requires both CLK and DATA to be bi-directional in order to handle all the required states. Top that off with 3 different 'standard' speeds, two different addressing modes, non-standard voltages often requiring voltage translation -- I2C is just a terrible excuse for a bus. In fact, I've never met a practicing geek who likes I2C, as it's nothing but headaches dealing with the corner cases, and whacking the chips when the bus goes catatonic. Ugh. Just terrible.
And CAN? That's worse. I don't want to raise my blood pressure too much, so suffice it to say that CAN was invented in the 80s so it could be implemented with small amounts of code and fairly simple hardware because: 80s. It requires very careful planning of every message type. There is a limit to the # of messages you can have on any one bus. The bus is not one speed, could be many common speeds. It's a standard that needs to be put into the past ASAP.
What should we use instead? I3C is trying to supplant I2C, but SPI is clearly the simple, fast alternative. UARTs these days (e.g. the common CP2102) can do 3.8 Mbaud easily - that ain't too bad. And if you need anything approaching 'real networking' --- then, gosh, use Real Networking: Ethernet. Even poky 100 Mb/s 4-wire Ethernet is better than CAN.
(note: any technology can have a 'perfect' niche, so sure, in certain applications. I2C could be optimal, and so could CAN; but generally, I claim those are mostly legacy applications.)
CAN is interesting in that the protocol is pretty complex, but from software point of view it's just send_packet() and register a handler for receive packets. The annoying thing is that MCUs don't have built-in CAN line drivers.
A new thing is 1000BASE-T1- Gigabit Ethernet over a single twisted pair. This is supposed to be the future in the auto world..
Comments
A nice advantage of SPI is that it can not lock up the master.
This is not true of I2C, where the slave could stretch the clock forever.
This is also not true of UART, where the slave just might not respond. But in fact both SPI and I2C can be simpler than UART since they are strictly master/slave. With a UART, the slave could send you unrequested data, which means your software has to handle asynchronous events. Even if it doesn't you probably have to implement timeouts and input flushing.
SPI is simpler than I2C in that it is a single-master bus, so accesses are atomic (at least at the bus level, within your RTOS is another story...).
You can use simple logic gates as SPI peripherals: for example, 74HC595 works as a SPI accessible 8-bit output port. This is important because such chips are the cheapest available (vs. I2C output port or UART to parallel..)
Despite all this simplicity, SPI is very fast.
Where UART has the advantage is software: picocom on Linux or Teraterm on Windows. Basically you don't have to develop any host-side software if you use a UART. I like to use the old ymodem protocol for embedded system firmware updates.. since again no host-side software has to be developed.
UART has another advantage, fungible cheap very-long runs when paired to balanced RS485 transceivers–at least, for relatively slow baud rates, and with decent shielded cable, you can get 56 kbps well over a kilometer. Better with some effort.
In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product).
I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...
OMG, I2C is... terrible, as others have commented, because a slave can hold up the bus 'forever'. Also, not frequently understood is the crappy protocol requires both CLK and DATA to be bi-directional in order to handle all the required states. Top that off with 3 different 'standard' speeds, two different addressing modes, non-standard voltages often requiring voltage translation -- I2C is just a terrible excuse for a bus. In fact, I've never met a practicing geek who likes I2C, as it's nothing but headaches dealing with the corner cases, and whacking the chips when the bus goes catatonic. Ugh. Just terrible.
And CAN? That's worse. I don't want to raise my blood pressure too much, so suffice it to say that CAN was invented in the 80s so it could be implemented with small amounts of code and fairly simple hardware because: 80s. It requires very careful planning of every message type. There is a limit to the # of messages you can have on any one bus. The bus is not one speed, could be many common speeds. It's a standard that needs to be put into the past ASAP.
What should we use instead? I3C is trying to supplant I2C, but SPI is clearly the simple, fast alternative. UARTs these days (e.g. the common CP2102) can do 3.8 Mbaud easily - that ain't too bad. And if you need anything approaching 'real networking' --- then, gosh, use Real Networking: Ethernet. Even poky 100 Mb/s 4-wire Ethernet is better than CAN.
(note: any technology can have a 'perfect' niche, so sure, in certain applications. I2C could be optimal, and so could CAN; but generally, I claim those are mostly legacy applications.)
I've done similar things with UARTs over long distance- I was about to write about it, but I actually have it on github:
https://github.com/jhallen/joes-sandbox/tree/master/hw/lined...
CAN is interesting in that the protocol is pretty complex, but from software point of view it's just send_packet() and register a handler for receive packets. The annoying thing is that MCUs don't have built-in CAN line drivers.
A new thing is 1000BASE-T1- Gigabit Ethernet over a single twisted pair. This is supposed to be the future in the auto world..
i2c-tools gets you pretty far if you have a userland i2c bus in linux
and spidev is not TOO hard to use if you don't need transactions.
Some FTDI chips can do I2C (also SPI), will i2c-tools work for it?
Otherwise the Arduinos with USB are a convenient way to connect I2C to a PC..
I've mostly used it with a beagleboneblack. Not sure if ftdi chips work. SPI seems hard to do with USB due to latency.