UART, SPI, & I2C

[Rhythmtech]

Serial communication protocols? An overview, what's the differences and why. When to use which and why.

[Mechatrommer]

yup why? i'm still not fully understand why. all i know is that it has something to do with application suitability (volt level, bps limit, no of lines required or some hardware specific etc). or maybe everybody who created it just want to show their protocol is more superb than others. and i strongly believe the reason of this is similar to why of the changing from serial or parallel port to usb (protocol) port. because its better than other, but.... everybody just choose whatever suits them from all the option. even if usb is the new thing, some people will stick to serial port. IMO.

for more detail, u can check the wiki, i've saved all the protocol desc, but still havent compare them side by side. so far.. i've used uart and spi, from what i can see, the main difference (for my concern) is the max datarate, uart is limited up to 2Mbps, where spi can go up to 10-20Mbps. if a chip got both uart and spi, i'll prefer spi due to this reason, if... the other end can understand spi, otherwise, i'll just use uart, if any. if there is no serial comm port? then i'll use my own serial protocol

[Ferroto]

Serial communication protocols? An overview, what's the differences and why. When to use which and why.

I2C and SPI are generally only used to interface internal components in the same physical PCB

I2C uses a 7-bit address byte to address the slave device so you have a maximum of 127 combinations, however 16 of those are reserved so you get 111 possible devices. Some external devices that are not MCU's have specific pins to set the address of the slave device in hardware. This presents another problem, I have recently decided to hack an old printer because I wanted to find out what was on the EEPROM which was a microchip EEPROM. The EEPROM had 4 pins to set the lower 4 bits of the 7-bit device address, meaning the upper 3 bits were zeros. This only allows 15 devices with schemes such as this. Now this was not a problem as I was only trying to extract the data off the device.

UART has two data lines going in two directions allowing both devices to communicate without a designated slave device. The disadvantage is that this type of protocol only supports two devices.

[RayJones]

UART has two data lines going in two directions allowing both devices to communicate without a designated slave device. The disadvantage is that this type of protocol only supports two devices.

Yes, but it can travel the world.

UART typically equals RS-232 asynchronous serial port.
The world used to be dominated by this form of serial data comms, and it still exists in many devices for low level access for reflashing etc.

SPI / I2C are internal busses within equipment and you can get cool devices that do a specific job.

SPI is the old traditional one, originally developed by Motorola at the time (now Freescale)

I2C was developed later by Philips to try to address some of the shortcoming like addressability that SPI has.

[alm]

The disadvantage of UART is that's asynchronous, so the clock on both sides needs to be pretty close (2% or so) to work, which often requires an external crystal (as opposed to internal RC oscillator). The disadvantage of SPI is that you need an enable line per slave, and multi-master is hard to implement. I²C needs only two lines for lots of devices, but because it's an open collector interface with a pull-up resistor, the total capacitance is limited. SPI is the fastest and simplest (enable high and dump data).

[Mechatrommer]

The disadvantage of UART is that's asynchronous, so the clock on both sides needs to be pretty close (2% or so) to work, which often requires an external crystal (as opposed to internal RC oscillator). The disadvantage of SPI is that you need an enable line per slave, and multi-master is hard to implement. I²C needs only two lines for lots of devices, but because it's an open collector interface with a pull-up resistor, the total capacitance is limited. SPI is the fastest and simplest (enable high and dump data).

yup! another main diff. of uart, they dont have clock line, so there is potential damage/corruption in the data if there is clock mismatch between the 2 ends or setting at diff. baudrate. spi is more foolproof in this matter coz it has clock line. not sure bout the i2c, yet to explore.

[Rhythmtech]

So do we need a show on it?  I am familiar with the basics, have used a lot of FTDI interface stuff, but would personally like to hear some Davetastic explanation of how to put it to work and why.

[RayJones]

What we are seeing with UART -> SPI -> I2C is evolution!

This is my take on this.

UART's produce the asynch format which harks way back to early last century in the teleprinter. As found in every post office etc. at the time.
These were mechanical behemoths and each bit was used to set code bars via a rotating motor - synced to the mains.
The code bars would only allow one "type arm" in the basket of  characters to operate at any one time.
When the last bit was received, the hammer came down, literally, and the selected character was slammed into the platten through a ribbon.
Being a mechanical beast, this was also a driving factor behind the qwerty keyboard as we know. The characters were deliberately randomised to minimise potential clashes as the mechanical type arms flailed backwards and forwards.

Great stuff!

Synchronous serial comms were then developed to help with the potential of async to lose synchronisation.
Synchronous modems provided Tx and Rx clocks, which of course clocked the data through. These clocks tended to run continuously, and "frame bits" were sent on the data to keep things synchronised.

Motorola then developed SPI for it's micro controller devices, which had limited pins.
SPI has the novel concept of "clock stop" where the clock is only sent when data is sent.
This simplified things greatly for the original purpose of exchanging data from one microcontroller to another. 8 bits could be reliably exchanged with only 3 lines.
However expansion of connected devices unleashed a flotilla of chip select lines, usually requiring 1of8 decoders, and therefore more pins/lines to drive these.

So Philips many years later developed I2C where each device is addressable, and the address to operate upon is part of the data stream sent. So the bus reduces back to clock and data and the world rejoiced when several peripherals were to be attached to a micro.

I2C is however more difficult to work with if all you want to do is a simple "port expander".
Common TTL style shift registers can easily be bolted onto a SPI port to provide extra I/O lines, cascaded in series for more bits if desired!

So each form still has it uses these days, and depends upon what you wish to achieve.

FWIW, my first interfacing effort to a micro was driving a "Model-50" teleprinter to a 6809 based computer. Worked a treat, and yes I used a UART to do the deed.

Nowadays I'm leaning towards CAN as it inherently allows multimaster operation with an inbuilt message priority scheme. And yes, it too is another form of serial data!

Cheers, Ray

[Rhythmtech]

That's awesome.  I love reading about tech in historical format. Thanks Ray

[alm]

Another common serial bus is 1-wire, which uses only one wire (plus ground). Even power can be provided over that one wire. It's even slower than I²C, and is used for slow stuff like temperature sensors.

[mikeselectricstuff]

Quick summary :
Uart
Advantages : single wire, easy interface to PCs,MCU UARTSs etc. range of standard physical interfaces (TTL, RS232, RS422, RS485) covers a big range of distance/speed capabilites with off-the-shelf hardware.
Disadvantages : Needs reasonable clock accuracy both ends. Max data rate in practice about 1mbit/sec (typically limited by UART capabilities).
Due to clock requirement, it's not generally practical to wake an MCU on reception and have the first character available once woken due to clock startup delays.

SPI
Advantages: Potentially very fast (10-20mbits/sec), very simple interface, very easy to implement in hard logic,FPGA or software.
Self-clocking so can wake an MCU on reception and have the data byte available once woken.
Flexible data word sizes

Disadvantages :
Multiple devices need multiple select lines.
Lack of standardisation of clock polarity, Select behaviour etc.
Single master only.

I2C
Advantages :
Only 2 wires to support multiple devices. Multimaster capability
Timing constraints of protocol reduce likelihood of false data (e.g. eeprom corruption) in noisy or powerup/down situations. 

Disadvantages :
More complex protocol than SPI, harder to level-shift or optoisolate due to bidirectional lines.
Speed up to 400kbit/sec (1mbit for a few devices), but in practice can be limited to lower rates by capacitance if tracks are long.
Self-clocking so can wake an MCU on reception and have the data byte available once woken.
Need for pullup resistor(s) can reduce power efficiency in some cases.

The issue of suitability for on-board/external interfaces isn't a direct characteristic of the interface, but  a consequence of the number of lines required and the way they are used.
You _could_ run SPI over RS232 or RS422, but you'd need more drivers and would run into skew issues at higher rates. I2C gets complicated due to the bidirectional nature, but you could run it on RS485 in principle, but in practice it's rarely worth the hassle.

 

[alm]

The bidirectional nature makes I²C also hard to isolate through optocouplers or pulse transformers. You basically need an I²C transceiver on both sides. I think NXP has an appnote that converts the I²C to something with four unidirectional lines, and uses opto's to isolate these lines. There are some devices in the RF isolation devices (eg. AD icoupler) lines that understand I²C.

[RayJones]

The sychronous serial formats will all run into problems with long runs if care is not taken to minimise skew of the clock against the data.

This is why I am warming to the CAN bus on a project at work, the clock is embedded in the data, as it was with floppy drives.
If more than 5 zeros or ones are sent in succession, the CAN devices insert "stuffing bits" to forcibly introduce a clock transition to keep things in step. Sure this make it harder to decode when you look at the stream on a logic analyser/CRO, but this is a truly self clocking data stream.

I don't know how you can call SPI or I2C self clocking when the clock runs alongside the data?