Serial vs Parallel, Sync vs Async

In this lesson:

• serial vs parallel: one bit at a time, or many at once
• synchronous vs asynchronous: a shared clock line, or an agreed-upon rate
• duplex: simplex, half-duplex, full-duplex
• where UART, SPI, I2C, and CAN land on these axes
• why nearly every modern fast bus went serial

These axes classify every protocol in this module, learn them once and the rest slots into place.

Axis 1: serial vs parallel

To move a byte between two chips, you can send all 8 bits at once over 8 wires (parallel) or one bit at a time over a single wire (serial).

PARALLEL (8 data lines)            SERIAL (1 data line)
 D7 ──────1                         D ──1─0─1─0─0─1─0─1──▶  (bits in time)
 D6 ──────0
 D5 ──────1                         one wire, bits sent sequentially
 D4 ──────0                         (+ usually a clock or agreed rate)
 ...        all 8 bits at one instant
 D0 ──────1

Intuitively parallel sounds faster, 8 bits per clock vs 1. But at high speed and any real distance, parallel loses:

• Skew: the 8 lines don't arrive at exactly the same time; as clocks rise, that timing spread caps the usable rate.
• Crosstalk & cost: many fast-switching parallel lines interfere, and they cost pins, traces, and connector size.

So the industry went serial: USB, SATA, PCIe, Ethernet, SPI, I2C, CAN are all serial. A single clean serial line clocked very fast beats many skewed parallel ones. Parallel survives only short-haul and on-chip (memory buses, some displays). Serial = fewer wires, longer reach, higher practical speed.

Axis 2: synchronous vs asynchronous

How does the receiver know when to sample each bit?

• Synchronous, a dedicated clock line is shared; the transmitter drives it, and the receiver samples the data line on each clock edge. No rate agreement needed, the clock is the timing. (SPI, I2C.)
• Asynchronous, there's no clock line. Both sides agree on a bit rate (baud) in advance; the receiver detects a start bit, then samples at that pre-agreed interval. (UART.)

SYNCHRONOUS (clock + data)          ASYNCHRONOUS (data only)
 CLK  ▁▁██▁▁██▁▁██▁▁██                       start    data bits        stop
 DATA ──1──0──1──1──             idle ▔▔▔▔╲___╱▔╲_╱▔▔╲__╱▔▔▔▔  (sampled at agreed baud)
      sample on each clock edge   receiver recovers timing from the start edge

The tradeoff: synchronous needs an extra wire (clock) but works at any speed both sides can follow and tolerates clock drift. Asynchronous saves the wire but requires both ends to have accurate, matched bit timing, a baud mismatch beyond a few percent garbles everything (a whole lesson later).

Axis 3: duplex, who can talk when

• Simplex, one direction only (a sensor that only transmits).
• Half-duplex, both directions, but one at a time, sharing a line (I2C's SDA, RS-485, CAN).
• Full-duplex, both directions simultaneously, on separate lines (SPI's MOSI+MISO; UART's TX+RX).

Where the protocols land

*CAN has no separate clock line; receivers resynchronize on bit edges, so it behaves async at the wire but with tight bit-timing rules.

This single table previews the whole module: the next lessons fill in each row's mechanics.

A terminology note

Don't conflate the peripheral/protocol with the electrical standard:

• UART is the on-chip peripheral and the framing (start/data/parity/stop). RS-232 and RS-485 are electrical standards (voltage levels, differential signaling) that carry UART framing over a wire. "UART" ≠ "RS-232".
• Likewise the logic-level TX/RX pins on your MCU are UART; a MAX232 or RS-485 transceiver converts those to the cable's electrical levels.

Gotchas

• Parallel isn't "faster" in practice. Skew and crosstalk cap parallel at high speed/distance, which is why fast modern buses are serial. Don't assume more wires = more throughput.
• Async demands matched timing. No shared clock means both ends must hold the agreed baud within a few percent (clock-drift budget). Synchronous buses sidestep this by shipping the clock.
• Sync costs a pin but buys flexibility. A clock line is an extra wire, but the bus then runs at any speed the slowest device tolerates and survives drift, handy for slow or variable-speed devices.
• Protocol ≠ electrical standard. UART framing vs RS-232/RS-485 levels; I2C logic vs the bus's pull-up electricals. Mixing the layers up causes wiring mistakes (e.g., connecting MCU UART pins straight to an RS-232 port).

TL;DR

• Serial vs parallel: serial sends one bit at a time over one line; parallel sends many at once over many lines. Skew and crosstalk make serial win at speed/distance, nearly every modern fast bus is serial.
• Synchronous vs asynchronous: synchronous shares a clock line (receiver samples on clock edges, SPI, I2C); asynchronous has no clock, so both ends use a pre-agreed baud and recover timing from a start bit (UART).
• Duplex: simplex (one way), half-duplex (one way at a time, shared line, I2C, CAN), full-duplex (both at once, separate lines, SPI, UART).
• Map: UART = serial/async/full-duplex; SPI = serial/sync/full-duplex; I2C = serial/sync/half-duplex; CAN = serial/differential/half-duplex.
• Keep protocol (UART framing, I2C logic) distinct from electrical standard (RS-232/RS-485 levels), they're different layers.