Electronics Guide

Serial Communication Protocols

Serial communication protocols form the backbone of data exchange in embedded systems, enabling processors to communicate with sensors, memory devices, displays, and other electronic components. Unlike parallel communication that transmits multiple bits simultaneously across many wires, serial protocols send data one bit at a time over fewer connections, reducing pin count, simplifying routing, and often achieving higher reliability over longer distances.

This article explores the major serial communication protocols used in embedded systems: UART for simple asynchronous communication, SPI for high-speed peripheral interfaces, I2C for multi-device buses, I2S for digital audio, and RS-232/RS-485 for industrial and long-distance applications. It also surveys smaller interfaces such as 1-Wire and the modern successors that extend these buses. Understanding these protocols enables engineers to select appropriate interfaces for specific requirements and implement robust communication in their designs.

A note on terminology: the older master/slave vocabulary still appears throughout datasheets and existing code, and this article retains it where a specification defines the terms that way. The industry is migrating to neutral alternatives, and each section below notes the current preferred names.

Fundamentals of Serial Communication

Serial communication transmits data sequentially, one bit following another over a single data line or differential pair. This approach contrasts with parallel communication, where multiple bits travel simultaneously on separate wires. While parallel interfaces can achieve high throughput over short distances, serial protocols dominate modern embedded systems due to their reduced complexity and superior signal integrity at higher speeds and longer distances.

Synchronous vs. Asynchronous Communication

Serial protocols divide into two fundamental categories based on how they coordinate data transfer timing:

Synchronous communication: A dedicated clock signal accompanies the data, explicitly indicating when each bit should be sampled. The clock signal eliminates timing ambiguity, allowing higher data rates and simpler receiver design. SPI and I2C exemplify synchronous protocols where a master device generates the clock that all participants use for timing reference.

Asynchronous communication: No separate clock signal exists. Instead, transmitter and receiver must agree in advance on the data rate (baud rate), and special start and stop bits frame each data byte, allowing the receiver to synchronize to each character independently. UART represents the quintessential asynchronous protocol, offering simplicity at the cost of lower maximum data rates and some bandwidth overhead for framing bits.

Signal Levels and Electrical Characteristics

Serial protocols specify electrical characteristics that determine compatibility, noise immunity, and maximum transmission distance:

Single-ended signaling: Data is represented as voltage levels relative to a common ground. TTL (0V/5V) and CMOS (0V/3.3V or lower) logic levels work well for short-distance, on-board communication but are susceptible to ground noise and offer limited range.

Differential signaling: Data is encoded as the voltage difference between two wires, providing excellent noise immunity since interference affects both wires equally and cancels out. RS-485 and LVDS use differential signaling for robust communication over longer distances and in noisy environments.

Open-drain/open-collector: Outputs can only pull a line low; pull-up resistors bring the line high when no device is driving it low. I2C uses this approach to enable multiple devices to share a bus without driver conflicts and to allow easy level shifting between different voltage domains.

Bus Topologies

Serial protocols support various connection arrangements:

Point-to-point: A dedicated connection links exactly two devices. UART and RS-232 typically operate in this configuration, simplifying addressing but requiring separate connections for each device pair.

Multi-drop bus: Multiple devices share common signal lines, with addressing or selection mechanisms determining which device participates in each transaction. I2C and RS-485 support this topology, reducing wiring complexity in systems with many peripherals.

Daisy chain: Devices connect in series, with each passing data to the next. Some SPI configurations use daisy chaining to reduce chip select lines when connecting multiple similar devices.

UART (Universal Asynchronous Receiver-Transmitter)

UART provides simple, asynchronous point-to-point serial communication. Its straightforward protocol, minimal pin requirements, and wide availability make it the default choice for debug consoles, GPS modules, Bluetooth interfaces, and countless other applications where simplicity outweighs the need for high speed or multi-device support.

UART Protocol Fundamentals

UART communication proceeds without a shared clock signal. Instead, both devices must configure identical parameters before communication begins:

Baud rate: The number of signaling events, or symbols, per second. Because UART encodes one bit per symbol, its baud rate and its raw bit rate are numerically identical, which is why the two terms are used interchangeably in this context. Rates typically range from 9600 to 115200 for general applications, though several megabaud is achievable with modern hardware. Common standard rates include 9600, 19200, 38400, 57600, and 115200 baud. Both devices must be configured for the same rate; the tolerance is finite but not generous, as the next section explains.

Data bits: The number of data bits per character, most commonly 8 bits but sometimes 5, 6, 7, or 9 bits for specialized applications.

Parity: An optional error detection bit calculated from the data bits. Options include none (most common), odd, even, mark (always 1), or space (always 0). Parity provides limited single-bit error detection but not correction.

Stop bits: One or two high bits following each character, providing time for the receiver to process the received byte and prepare for the next start bit. One stop bit is standard; two stop bits may be used for slower devices or longer connections.

A typical configuration notation such as "115200 8N1" specifies 115200 baud, 8 data bits, no parity, and 1 stop bit.

Frame Structure

Each UART frame begins with a start bit (logic low), followed by the data bits transmitted least significant bit first, an optional parity bit, and one or two stop bits (logic high). The line idles at logic high between frames, allowing the receiver to detect the falling edge that marks each start bit.

For 8N1 configuration, each byte requires 10 bit periods (1 start + 8 data + 1 stop), meaning actual data throughput is 80 percent of the raw baud rate. At 115200 baud, this yields approximately 11,520 bytes per second maximum throughput.

The falling edge of the start bit is the receiver's only timing reference for the entire frame. A typical UART receiver oversamples the line, commonly at sixteen times the bit rate, and samples each bit near the center of its window. That center-sampling is what sets the tolerance for clock mismatch: the accumulated timing error at the last bit of the frame must stay well inside half a bit period. For a 10-bit 8N1 frame the combined transmitter and receiver error should therefore remain within roughly 2 percent, which is why a clock source with a few percent of drift can pass at 9600 baud yet fail intermittently at 115200 baud. Longer frames, such as 8 data bits with parity and two stop bits, tighten the budget further.

Hardware Connections

Basic UART communication requires only three connections:

TX (Transmit): Output from the transmitting device, connected to the receiving device's RX pin.

RX (Receive): Input to the receiving device, connected to the transmitting device's TX pin.

GND (Ground): Common reference for both devices, essential for proper signal interpretation.

Note that TX connects to RX and vice versa; this crossover connection is fundamental to UART communication. Some interfaces include additional hardware flow control signals (RTS/CTS or DTR/DSR) to prevent data loss when receivers cannot keep up with incoming data.

Flow Control

When a receiver cannot process incoming data fast enough, flow control mechanisms prevent data loss:

Hardware flow control (RTS/CTS): Each device drives an RTS output and monitors a CTS input, and the two signals cross between devices: one end's RTS wires to the other end's CTS. In modern UART practice each signal describes the receiver, not the transmitter. A device asserts its RTS output to mean "my receive buffer has room, keep sending," and deasserts it as the buffer fills. Before sending a character, a device checks its CTS input; if CTS is deasserted, it holds off. This inverts the term's original meaning, since RTS in the original modem-oriented standard meant "request to send." The reinterpretation is deliberate and now standard, and the signal is often labeled RTR (ready to receive) to reflect it. Hardware flow control provides reliable, low-latency backpressure but requires two additional pins, and the transmitter must stop within a character or two of CTS deasserting, so a small amount of receive headroom is still necessary.

Software flow control (XON/XOFF): Special control characters (0x11 for XON and 0x13 for XOFF) signal the transmitter to pause or resume sending. This approach needs no extra pins but consumes bandwidth, responds more slowly than hardware signaling because the stop character must queue behind data already in flight, and cannot carry binary data that might contain these byte values unless an escaping scheme is added.

Implementation Considerations

Successful UART implementation requires attention to several practical factors:

Baud rate accuracy: Clock source accuracy directly affects achievable baud rates. Crystal oscillators provide sufficient accuracy; internal RC oscillators may drift with temperature, causing communication errors at higher baud rates.

Buffer management: Hardware UART peripherals include transmit and receive buffers (often FIFOs) that smooth out timing variations. Software must read received data before buffers overflow and must not write faster than the transmit buffer can empty.

Interrupt vs. polling: Polling-based implementations are simpler but may miss characters during other processing. Interrupt-driven approaches, particularly with DMA for high-throughput applications, provide more reliable operation.

Voltage compatibility: UART signals at the logic level (3.3V or 5V) have limited range and noise immunity. Level shifters may be needed when connecting devices with different logic voltage levels.

SPI (Serial Peripheral Interface)

SPI provides high-speed, synchronous, full-duplex communication between a master device and one or more peripheral devices. Originally developed by Motorola in the 1980s, SPI has become the preferred interface for applications demanding high throughput, including flash memory, displays, ADCs, DACs, and high-speed sensors.

An important caveat frames everything that follows: SPI has no governing specification. No standards body publishes an SPI document, and no conformance test exists. What circulates is a widely followed convention, which is why signal names, chip select polarity, word lengths, and idle-state behavior vary between vendors. The peripheral's datasheet, not a standard, is the authority for any given part.

SPI Architecture

SPI operates as a master-slave protocol where a single master controls all communication timing and peripheral selection. The master generates the clock signal that synchronizes all data transfers, eliminating the need for precise timing agreement between devices.

Four signals define a basic SPI connection:

SCLK (Serial Clock): Clock signal generated by the master, typically ranging from a few hundred kilohertz to tens or hundreds of megahertz depending on the peripheral capabilities.

MOSI (Master Out, Slave In): Data line from master to slave, also called SDO (Serial Data Out) or DI (Data In) depending on perspective.

MISO (Master In, Slave Out): Data line from slave to master, also called SDI (Serial Data In) or DO (Data Out).

CS/SS (Chip Select/Slave Select): Active-low signal that enables a specific peripheral; each slave device requires its own chip select line from the master.

Because SDO and SDI are defined from each device's own point of view, they are a recurring source of wiring errors: one board's SDO must reach the other board's SDI. MOSI and MISO avoid that ambiguity by naming both endpoints. Newer datasheets increasingly use controller and peripheral in place of master and slave, with the data lines named COPI (controller out, peripheral in) and CIPO (controller in, peripheral out), and chip select written as CS. The signals and timing are unchanged; only the labels differ, and mixed vocabulary across two datasheets in one design is common enough to warrant checking the direction of every line against a block diagram.

Clock Polarity and Phase

SPI defines four operating modes based on two parameters that must match between master and slave:

CPOL (Clock Polarity): Defines the idle state of the clock signal. CPOL=0 means the clock idles low; CPOL=1 means it idles high.

CPHA (Clock Phase): Defines when data is sampled relative to clock edges. CPHA=0 samples on the first clock edge (leading edge); CPHA=1 samples on the second clock edge (trailing edge).

The four resulting modes are typically numbered 0 through 3:

Mode 0 (CPOL=0, CPHA=0): Clock idles low, data sampled on rising edge, shifted on falling edge. Most common mode.

Mode 1 (CPOL=0, CPHA=1): Clock idles low, data sampled on falling edge, shifted on rising edge.

Mode 2 (CPOL=1, CPHA=0): Clock idles high, data sampled on falling edge, shifted on rising edge.

Mode 3 (CPOL=1, CPHA=1): Clock idles high, data sampled on rising edge, shifted on falling edge.

Peripheral datasheets specify the required mode; mismatched settings cause data corruption.

Data Transfer Mechanism

SPI implements full-duplex communication: data simultaneously flows in both directions during each transaction. Conceptually, the master and slave each contain shift registers connected in a ring. Each clock cycle shifts one bit out of each device while shifting one bit in, with MOSI carrying master-to-slave data and MISO carrying slave-to-master data.

A typical transaction proceeds as follows:

1. Master asserts (drives low) the chip select for the target peripheral.

2. Master generates clock pulses while simultaneously outputting command/data bits on MOSI and reading response bits from MISO.

3. After the required number of clock cycles, master deasserts chip select, completing the transaction.

Word length is not fixed by the protocol; 8-bit transfers are most common, but 16-bit, 32-bit, or arbitrary lengths are possible depending on peripheral requirements.

Multi-Slave Configurations

SPI supports multiple peripherals through two primary approaches:

Independent chip selects: Each peripheral has its own chip select line. The master enables only one peripheral at a time. This configuration offers flexibility but consumes one GPIO pin per peripheral.

Daisy chain: Peripherals connect in series, with each device's output feeding the next device's input. All devices share one chip select. Data shifts through all devices in the chain, requiring careful coordination of transaction length. This configuration reduces pin count but limits addressing flexibility.

Dual, Quad, and Octal SPI

Serial flash memory pushed SPI beyond its original single-lane form. Reading code or graphics assets one bit per clock became the bottleneck in systems that execute directly from external flash, so vendors widened the data path while keeping the clock and chip select unchanged.

Dual SPI: The MOSI and MISO pins are repurposed as two bidirectional data lines, doubling throughput at a given clock rate.

Quad SPI (QSPI): Four bidirectional data lines quadruple throughput. Two pins that serve as write-protect and hold in single-lane mode become the third and fourth data lines. QSPI is now the common interface for external NOR flash on microcontrollers.

Octal SPI: Eight data lines, used with high-density flash and PSRAM where memory bandwidth is critical.

These modes are half-duplex by nature: the shared lines cannot carry both directions at once, so a transaction separates into command, address, dummy, and data phases. The dummy cycles give the memory time to fetch the first word before the controller begins clocking data out. Many controllers pair these modes with an execute-in-place memory-mapped window, so the processor reads external flash through ordinary load instructions while hardware translates each access into a flash read transaction. Double-data-rate variants transfer on both clock edges, doubling throughput again at the cost of tighter timing margins.

Advantages and Limitations

SPI offers several compelling advantages:

High speed: Clock rates of 10 MHz, 50 MHz, or higher are common, with some peripherals supporting over 100 MHz. The synchronous nature and push-pull drivers enable these high speeds.

Full duplex: Simultaneous bidirectional data transfer maximizes throughput for applications that need it.

Simple protocol: No addressing, acknowledgments, or complex state machines; the protocol is straightforward to implement in software if needed.

Flexible word length: No inherent restriction on transaction size enables efficient transfer of arbitrary data structures.

However, SPI also has limitations:

Pin count: Requires four signals plus one chip select per peripheral, consuming GPIO resources.

Short distance: Single-ended signaling limits practical distances to perhaps a meter; longer runs require reduced clock speeds or signal conditioning.

No acknowledgment: The protocol provides no inherent confirmation that data was received correctly; higher-level protocols must implement error detection if needed.

Master-only initiation: Slaves cannot initiate communication; additional interrupt lines are often needed for slaves to signal events to the master.

I2C (Inter-Integrated Circuit)

I2C, developed by Philips (now NXP) in the early 1980s, provides a multi-master, multi-slave serial bus using only two wires. Its addressing capability enables dozens of devices to share a single bus, making it ideal for systems with many low-speed peripherals such as sensors, EEPROMs, real-time clocks, and port expanders.

Unlike SPI, I2C is a formally specified bus. NXP maintains the specification as document UM10204; revision 7, published in October 2021, is the current version. That revision replaced the terms master and slave with controller and target, aligning I2C's vocabulary with the newer I3C bus specification. The electrical behavior and protocol were not changed. This article uses the older terms alongside the new ones because both remain in circulation, but new datasheets and driver APIs increasingly use controller and target.

I2C Bus Architecture

I2C uses two bidirectional signals:

SCL (Serial Clock): Clock signal, driven by the master during transactions. In multi-master systems, clock synchronization and arbitration mechanisms allow multiple masters to coexist.

Arbitration deserves a closer look, because it is where the open-drain design pays off. Since any device can pull a line low and none can force it high, the bus performs a wired-AND of everything driving it. If two masters start a transaction at nearly the same moment, each watches SDA while transmitting. A master that drives a 1 but reads back a 0 knows another master is driving a 0 and has therefore won; the loser withdraws immediately and retries later. The winner never learns a collision occurred and its transaction proceeds without corruption, so arbitration is non-destructive and costs no bandwidth. The same wired-AND behavior synchronizes the clock: SCL stays low until every master has released it, so the bus automatically runs at the pace of the slowest participant.

SDA (Serial Data): Bidirectional data line used for both commands and data in both directions.

Both lines use open-drain (or open-collector) drivers with external pull-up resistors. Devices can only pull lines low; when released, the pull-ups return lines to high. This arrangement prevents driver conflicts and enables the bus to operate across different voltage domains with appropriate pull-up resistor placement.

Pull-up resistor values represent a trade-off: smaller values enable faster rise times and higher speeds but increase power consumption; larger values save power but limit maximum bus speed. Typical values range from 1k to 10k ohms depending on bus capacitance and speed requirements.

Addressing and Device Selection

I2C uses 7-bit or 10-bit device addresses to select specific peripherals on the bus. Each device has a unique address, often partially fixed by the manufacturer with some bits configurable via address pins. This addressing eliminates the need for dedicated chip select lines.

Some 7-bit addresses are reserved: 0x00 for the general call (broadcast), and the ranges 0x01-0x07 and 0x78-0x7F for special purposes such as CBUS compatibility, 10-bit addressing, and high-speed mode entry. Excluding these reserved values, roughly 112 of the 128 possible addresses (0x08-0x77) remain available for devices. Address conflicts can still occur when multiple devices of the same type are needed; many chips therefore provide address-select pins that allow a few instances of the same device on one bus.

Protocol Structure

I2C communication follows a defined structure:

Start condition: The master signals transaction start by pulling SDA low while SCL is high. This unique condition (data changing while clock is high) cannot occur during normal data transfer and reliably indicates transaction beginning.

Address byte: Following the start condition, the master sends a 7-bit device address plus a read/write bit (0 for write, 1 for read). The addressed device acknowledges by pulling SDA low during the ninth clock pulse.

Data transfer: Data bytes follow, each consisting of 8 bits sent MSB first, followed by an acknowledge bit from the receiver. For writes, the slave acknowledges each byte from the master. For reads, the master acknowledges each byte from the slave (or sends a NACK to signal the last byte).

Stop condition: The master signals transaction end by releasing SDA (letting it go high) while SCL is high. This opposite of the start condition indicates transaction completion.

Repeated start: Instead of a stop, the master can issue another start condition to begin a new transaction without releasing the bus. This is essential for atomic read operations where the device register must be written before reading its value.

Clock Stretching

I2C allows slaves to slow down communication by holding SCL low after the master releases it. This clock stretching gives slow devices time to prepare data or complete processing before the next bit transfer. The master must monitor SCL and wait for it to go high before proceeding, ensuring it does not outrun slave capabilities.

Not all devices support clock stretching, and excessive stretching can cause timeouts in some masters. Designers must verify that all devices on a bus have compatible timing characteristics.

Speed Modes

I2C defines several speed modes to accommodate different device capabilities:

Standard mode: Up to 100 kbit/s. This is the baseline that essentially every bidirectional I2C device supports.

Fast mode: Up to 400 kbit/s, widely supported by modern devices.

Fast mode plus: Up to 1 Mbit/s, requiring stronger output drivers and adjusted timing parameters.

High-speed mode: Up to 3.4 Mbit/s, using a more complex protocol with a special entry sequence and an active current-source pull-up on the clock line during the high-speed transfer.

Ultra-fast mode: Up to 5 Mbit/s. This is a departure from the rest of the family: it is push-pull and unidirectional, so it supports neither reads, nor acknowledgment, nor multiple masters, and it is used only in write-only applications such as driving LED controllers.

The bus operates at the speed of its slowest device, as faster devices must accommodate the timing requirements of slower ones. Note also that these figures are clock rates rather than useful data rates. Every byte carries a ninth acknowledge bit, and each transaction spends additional clocks on the start condition, address byte, and stop condition, so a 400 kbit/s bus reading two bytes from a sensor register delivers considerably less than 400 kbit/s of payload.

Implementation Considerations

Successful I2C implementation requires attention to several factors:

Pull-up resistor selection: Must balance rise time (affected by bus capacitance) against current consumption. The specification caps bus capacitance at 400 pF for Standard and Fast modes and 550 pF for Fast-mode Plus. Because the pull-up resistance and the bus capacitance form an RC network, the resistor value follows from the capacitance and the mode's rise-time limit, while the low end is bounded by how much current the weakest device on the bus can sink while still holding a valid low level.

Bus capacitance: Long traces, multiple devices, and poor routing increase capacitance, limiting maximum speed. Bus buffers or repeaters may be needed for extensive buses.

Level shifting: When connecting devices with different voltage levels, bidirectional level shifters designed for open-drain signals are required.

Address conflicts: Multiple devices with the same address cannot coexist on one bus. Solutions include I2C multiplexers, programmable addresses, or separate buses.

Error handling: Bus lockup can occur if a slave holds SDA low (perhaps due to interrupted transfer). Recovery typically requires toggling SCL until SDA releases, then issuing a stop condition. This scenario is common after a reset that interrupts a read: the target is mid-byte, still driving SDA, and will not release it until it receives the clocks it expects. Boards that must recover unattended should route SCL so firmware can bit-bang it during startup.

SMBus, PMBus, and I3C

Several buses build on I2C's electrical foundation while tightening or extending the protocol. Recognizing them matters in practice, because a device specified for one may misbehave on a bus designed for another.

SMBus (System Management Bus): Originating in PC power management and still ubiquitous in laptop batteries, temperature sensors, and server management hardware, SMBus narrows I2C's tolerances into guarantees. It defines a minimum clock frequency and a transaction timeout, so a stalled device is detected and the bus recovers rather than hanging indefinitely. It also specifies fixed voltage thresholds instead of I2C's supply-relative ones, and standardizes a set of transaction formats along with an optional packet error checking byte. The practical consequence is that an I2C target relying on long clock stretching can trip an SMBus controller's timeout.

PMBus (Power Management Bus): A layer on top of SMBus that standardizes the command set for digitally controlled power converters, defining how to set output voltages, read back current and temperature telemetry, and report faults. It lets a system monitor and trim its power rails without a vendor-specific driver for every regulator.

I3C: Specified by the MIPI Alliance as I2C's successor, I3C keeps the two-wire form factor and can share a bus with legacy I2C targets, easing migration. It switches to push-pull drivers for most traffic, which removes the pull-up rise-time ceiling and raises the base data rate roughly an order of magnitude above Fast-mode Plus, with optional higher-speed modes beyond that. It also fixes I2C's long-standing irritations: targets receive addresses through dynamic assignment rather than fixed factory values, eliminating address conflicts, and in-band interrupts let a target signal the controller over the two existing wires instead of a separate interrupt pin. Sensor hubs in mobile devices were the first significant adopters.

I2S (Inter-IC Sound)

I2S, also developed by Philips, is a synchronous serial protocol specifically designed for digital audio data transfer between integrated circuits. It provides a standardized interface for connecting digital audio sources to DACs, ADCs, codecs, and digital signal processors in audio equipment.

I2S Signal Structure

I2S uses three main signals:

SCK/BCLK (Serial Clock/Bit Clock): Clock signal that times each bit transfer, running at a frequency equal to the sample rate multiplied by the number of bits per sample multiplied by the number of channels (typically 2 for stereo).

WS/LRCK (Word Select/Left-Right Clock): Indicates which audio channel is being transmitted. Low typically indicates left channel, high indicates right channel. The frequency equals the audio sample rate.

SD (Serial Data): The audio data stream, transmitted MSB first. Multiple data lines may be used for more channels or bidirectional operation.

An optional master clock (MCLK), typically 256 or 384 times the sample rate, may be provided to synchronize internal processing in audio devices.

Data Format

Standard I2S transmits data MSB first, with the MSB appearing one clock cycle after the word select transition. This one-clock delay is a defining characteristic of I2S, distinguishing it from similar but incompatible formats.

Several related formats exist:

Left-justified: MSB appears immediately with the word select transition, with no delay.

Right-justified: LSB aligns with the word select transition, useful for devices with fixed word lengths.

DSP/PCM mode: Short word select pulse with data immediately following.

Devices must be configured to matching formats; mismatches cause audio distortion or complete failure.

Audio Parameters

I2S accommodates various audio configurations:

Sample rates: Common rates include 8 kHz (telephony), 44.1 kHz (CD audio), 48 kHz (professional audio/video), 96 kHz, and 192 kHz (high-resolution audio).

Bit depths: 16-bit, 24-bit, and 32-bit are common, with the I2S frame size determining the available resolution.

Channels: Standard I2S handles stereo (two channels), but extensions using multiple data lines support multi-channel audio for surround sound applications.

The more common route to higher channel counts is time-division multiplexing. TDM mode reuses the I2S pins but reinterprets the word select signal as a frame sync marking the start of a frame that contains many channel slots in sequence rather than a left and right half. Eight slots is typical, and sixteen is supported by many devices. A single data line then carries all channels, which is how automotive head units, conference systems, and multi-microphone arrays connect numerous converters to one processor port. The bit clock scales with the slot count, so a TDM link runs proportionally faster than the equivalent stereo I2S link and demands correspondingly more attention to routing.

Clock Relationships and Jitter

Audio quality depends critically on clock stability. The bit clock, word clock, and master clock must maintain precise phase relationships derived from a common source. Clock jitter (timing variation) translates directly to audio distortion, making low-jitter clock generation essential for high-fidelity applications.

Systems commonly use either:

Master mode: The audio processor generates all clocks, providing optimal control over timing relationships.

Slave mode: An external master (such as an audio codec) provides clocks, which the processor must synchronize to.

Asynchronous sample rate conversion may be needed when connecting devices with independent clock sources.

RS-232

RS-232, formally known as TIA-232, is a long-established standard for serial communication between data terminal equipment (DTE) and data communication equipment (DCE). Though largely superseded by USB for direct computer connections, RS-232 remains common in industrial equipment, legacy systems, and applications requiring simple, reliable point-to-point communication.

Electrical Characteristics

RS-232 uses bipolar signaling with voltage levels far outside normal logic levels:

Logic high (Mark, 1): -3V to -15V (typically -12V)

Logic low (Space, 0): +3V to +15V (typically +12V)

The inverted voltage convention (negative = 1) and wide voltage swing provide noise immunity superior to TTL-level signals. The region between -3V and +3V is undefined, providing noise margins on both sides.

Note that RS-232 defines only the electrical layer and connector. The framing on the wire is ordinary UART framing, which is why an RS-232 port and a logic-level UART are configured with the same parameters and differ only in signaling voltage. The inversion is worth remembering when probing: an idle RS-232 line sits at a negative voltage, whereas an idle TTL UART line sits high.

RS-232 transceivers (such as the MAX232 family) convert between logic levels and RS-232 levels, typically using charge pump voltage converters to generate the required positive and negative voltages from a single supply.

The standard's classic limits are modest: roughly 20 kbit/s over a cable whose total capacitance stays within about 2500 pF, which is where the widely quoted 15 meter (50 foot) maximum originates. That figure is a consequence of cable capacitance rather than a hard rule, so short low-capacitance cable often runs far faster in practice, and contemporary transceivers routinely support 115.2 kbit/s and above. Later revisions of the standard relaxed the original rate limit, but designers pushing well past it should treat the result as empirical rather than guaranteed.

Connector and Pinout

The original RS-232 specification used a 25-pin D-subminiature connector, though the 9-pin DE-9 connector (commonly miscalled DB-9) became the practical standard for most applications. Key signals on the DE-9 include:

Pin 2 (RXD): Receive Data, input to DTE

Pin 3 (TXD): Transmit Data, output from DTE

Pin 5 (GND): Signal Ground

Pin 7 (RTS): Request To Send

Pin 8 (CTS): Clear To Send

Pin 4 (DTR): Data Terminal Ready

Pin 6 (DSR): Data Set Ready

Pin 1 (DCD): Data Carrier Detect

Pin 9 (RI): Ring Indicator

Many applications use only TXD, RXD, and GND, ignoring the handshaking signals or strapping them to fixed states.

Null Modem Connections

RS-232 was designed for connecting terminals (DTE) to modems (DCE), with specific signal directions for each role. Connecting two DTE devices directly requires a null modem cable that crosses the appropriate signals: TXD connects to RXD, and handshaking lines are crossed or looped back as needed for the specific application.

Modern Usage

Despite its age, RS-232 persists in several contexts:

Industrial and scientific equipment: Many instruments, PLCs, and industrial devices provide RS-232 ports for configuration and data transfer.

Embedded development: Serial console access via RS-232 or TTL serial remains common for debugging and initial configuration.

Legacy system integration: Connecting to older equipment often requires RS-232 interfaces.

USB-to-RS-232 adapters enable modern computers lacking native serial ports to communicate with RS-232 devices, bridging the gap between contemporary and legacy equipment.

RS-485

RS-485 (TIA-485) is a differential serial communication standard designed for multi-drop networks over long distances in electrically noisy environments. It provides the physical layer for many industrial protocols and remains a workhorse for industrial automation, building control, and distributed sensor networks.

Differential Signaling

RS-485 encodes data as the voltage difference between two wires (traditionally labeled A and B, though naming conventions vary):

Logic 1 (mark, idle): A is negative relative to B, by at least 200 mV at the receiver

Logic 0 (space): A is positive relative to B, by at least 200 mV at the receiver

The 200 mV threshold is the receiver's requirement, and the gap between it and the driver's much larger output swing is the noise budget the link runs on. Equally important is the common-mode range: receivers must interpret the difference correctly even when both wires sit several volts above or below the local ground, which is what allows devices on separate power systems to communicate. Differential signaling provides excellent common-mode noise rejection, because interference that affects both wires equally does not change the voltage difference and thus does not corrupt data. This enables reliable communication in industrial environments with motors, relays, and other noise sources. A third conductor tying the grounds together is still recommended, since the common-mode range is generous but not unlimited.

The A and B labels are a well-known source of trouble. The standard's convention is the one above, but many transceiver datasheets label the non-inverting pin A and the inverting pin B in a way that produces the opposite sense, and equipment vendors variously mark terminals as plus and minus, D+ and D-, or TxD+ and TxD-. Naming does not affect the physics, and reversing the pair simply inverts the received data, which typically presents as a link that never receives a valid frame. Because the failure is easy to diagnose and harmless to test, swapping the two wires is a standard first step when a new RS-485 link fails to communicate.

Network Topology

RS-485 supports multi-drop configurations with up to 32 unit loads on a single bus. The unit load is a measure of the loading a receiver places on the bus rather than a device count: the standard defines the driver's capability in terms of how many unit loads it can drive, so transceivers rated at a fraction of a unit load allow proportionally more nodes. Quarter-unit-load parts permit 128 nodes and eighth-unit-load parts 256, which is the origin of the frequently quoted 256-device figure. All devices share the same pair of wires, with addressing or protocols determining which device responds at any time.

The recommended topology is a linear bus with devices tapped off the main cable rather than star or tree configurations. Stubs connecting each device to the trunk should be as short as practical, because a long stub behaves as an unterminated transmission line and reflects energy back onto the bus. Termination resistors (typically 120 ohms, matching the characteristic impedance of twisted-pair cable) at the two physical ends of the bus prevent signal reflections that would cause data errors. Termination belongs at the ends and nowhere else; a resistor added at an intermediate node is a common field error that loads the bus and reduces the differential swing.

Half-Duplex and Full-Duplex Operation

RS-485 supports two operational modes:

Half-duplex (2-wire): A single twisted pair carries data in both directions, but not simultaneously. Devices must coordinate transmission to avoid collisions, typically through master-slave protocols where only the master initiates transactions and slaves respond only when addressed.

Full-duplex (4-wire): Separate twisted pairs for each direction enable simultaneous bidirectional communication. This configuration uses more cabling but simplifies protocols and improves throughput.

Driver enable control is critical in half-duplex systems: the transmitting device enables its driver only while transmitting, then immediately returns to receive mode. Failure to properly control driver enable causes bus contention and data corruption.

Distance and Speed

RS-485 supports impressive distance and speed combinations:

Maximum distance: Up to 1200 meters (4000 feet) at lower data rates

Maximum speed: Up to 10 Mbps at short distances (less than 10 meters)

Distance and speed trade off: longer cables limit maximum speed due to cable capacitance and signal propagation effects. Common configurations include 9600 baud at maximum distance or 1 Mbps at roughly 100 meters. Over the middle of the range the product of distance and bit rate is roughly constant for a given cable type, which makes it a serviceable rule of thumb, though the relationship flattens at both extremes and the published curves are guidance rather than guarantees. Cable quality, termination, and the noise environment all shift the achievable combination.

Biasing and Failsafe

When no device is transmitting (bus idle), RS-485 lines float at indeterminate voltages. Without proper biasing, receivers may interpret noise as valid data. Failsafe biasing ensures the bus assumes a known state when idle:

Pull-up on B: A resistor (often in the range of a few hundred ohms to about a kilohm) to the positive supply

Pull-down on A: A resistor of matching value to ground

The pair holds A below B while the bus is idle, which is the mark state, so idle receivers output a steady logic high exactly as an idle UART line should. Sizing them is a divider calculation rather than a guess: the two bias resistors work against the terminations, which appear in parallel as roughly 60 ohms on a properly terminated bus, and the values must be small enough to force the idle differential past the receiver's 200 mV threshold with margin, yet large enough to avoid loading the bus so heavily that an active driver cannot produce full swing.

These resistors should be installed at only one point on the bus, typically at the master; duplicating them at every node is a frequent mistake that collapses the differential swing. Many modern transceivers advertise internal failsafe receivers, which achieve the same end differently by shifting the receiver's own threshold slightly so that an undriven bus reads as a mark without any external bias network. Where every transceiver on a bus has that feature, external biasing is unnecessary. Distinguishing the two mechanisms matters, because a bus mixing failsafe and non-failsafe receivers still needs external bias for the sake of the latter.

Common Protocols

RS-485 provides only the physical layer; higher-level protocols define addressing, framing, and error handling:

Modbus RTU: Widely used industrial protocol with defined message format, addressing, and CRC error checking.

DMX512: Entertainment lighting control protocol.

BACnet MS/TP: Building automation protocol.

PROFIBUS: Industrial automation protocol popular in Europe.

Custom protocols are also common in proprietary systems, using RS-485's robust physical layer with application-specific message formats.

Other Serial Interfaces

Beyond the major protocols above, several narrower interfaces appear often enough in embedded designs to be worth recognizing.

1-Wire

Developed by Dallas Semiconductor, now part of Analog Devices, 1-Wire reduces the bus to a single data line plus ground. Devices can even draw operating power from that data line, storing charge in a small capacitor while the line idles high, an arrangement known as parasitic power that lets a sensor reach the bus over two conductors rather than three.

Timing carries the information that a clock would otherwise provide. The master pulls the line low and the duration of the pulse distinguishes a zero from a one, with the master releasing the line so the target can respond within a defined window. Data rates are low, on the order of tens of kilobits per second in standard mode, but the bus tolerates long cable runs and casual wiring that would defeat I2C. Every device carries a globally unique 64-bit identifier programmed at manufacture, and a search algorithm lets the master enumerate an entire bus without prior knowledge of what is attached, so devices can be added without configuring addresses. Digital thermometers, identification tokens, and consumable authentication chips are the characteristic applications.

LIN

LIN (Local Interconnect Network) is a single-wire automotive bus built directly on standard UART framing, which lets a plain microcontroller UART serve as the controller with only a transceiver added. It was created as an inexpensive companion to CAN for the many low-bandwidth functions in a vehicle that do not justify CAN's cost, such as window and seat motors, mirrors, rain sensors, and interior lighting. Communication is strictly master-scheduled: the master transmits a header containing a frame identifier and the designated slave supplies the data, so there is no arbitration to resolve. Speeds reach roughly 20 kbit/s. LIN networks typically hang off a node that also sits on the vehicle's CAN bus, forming a low-cost tier beneath it.

Microwire and Related Predecessors

Microwire, introduced by National Semiconductor, is a three-wire synchronous interface that predates and closely resembles SPI, operating in what SPI would call mode 0 with fixed word lengths. Small serial EEPROMs still use it. Because the signaling is compatible, an SPI controller can generally drive a Microwire device once the word length and chip select behavior are configured correctly, and the distinction is now largely historical.

Interfaces Covered Elsewhere

Three widely used serial technologies fall outside this article's scope because each merits separate treatment. CAN provides a differential, multi-master bus with priority-based arbitration and strong error handling for automotive and industrial control. USB supplies host-driven, enumerated, high-speed connectivity that displaced RS-232 for most computer peripherals. Ethernet carries higher-layer networking and, in its industrial variants, deterministic real-time traffic. See the related topics below.

Protocol Selection Guidelines

Selecting the appropriate serial protocol requires balancing multiple factors against application requirements:

Speed Requirements

When data rate is the primary concern:

SPI: Best choice for high-speed peripheral communication, routinely achieving 10-50 MHz and potentially over 100 MHz with suitable devices.

UART: Adequate for moderate speeds (typically under 1 Mbps), simple to implement but not designed for high throughput.

I2C: The slowest of the three in practice, with 400 kbit/s Fast mode the usual ceiling and 1 Mbit/s available in Fast-mode Plus. Protocol overhead and open-drain rise times reduce useful throughput further, so I2C suits peripherals where bus simplicity and low pin count outweigh speed. Where I2C's wiring economy is wanted at higher rates, I3C is the modern answer.

Number of Devices

When connecting multiple peripherals:

I2C: Excellent for many devices sharing two wires, with addressing built into the protocol.

SPI: Each device needs a chip select, consuming GPIO pins; best for a small number of high-speed devices.

RS-485: Supports up to 32 (or 256) devices on a shared bus, ideal for distributed systems.

Distance Requirements

When communication distance exceeds a few meters:

RS-485: Best choice for long-distance communication, supporting 1200+ meters with differential signaling.

RS-232: Moderate distance capability (15 meters typical), good for point-to-point connections.

SPI/I2C: Limited to short distances (typically under 1 meter for SPI, a few meters for I2C with reduced speed).

Noise Environment

In electrically noisy environments:

RS-485: Differential signaling provides excellent noise rejection.

RS-232: Better noise immunity than logic-level signals due to larger voltage swings.

SPI/I2C/UART: Vulnerable to noise; require shielding or reduced speed in challenging environments.

Simplicity and Pin Count

When minimizing complexity and connections:

I2C: Only two wires for any number of devices, at the cost of pull-up resistors and address management.

UART: Simple protocol with minimal pins (two or three for basic operation), but only two endpoints per link.

SPI: More complex, requiring four or more signals and one additional chip select per peripheral.

Galvanic Isolation

One requirement overrides most others when it applies. Equipment connected to mains-powered machinery, medical instrumentation, and any link crossing between separately grounded systems may need galvanic isolation, and the protocol choice strongly affects how difficult that is to provide. Unidirectional single-ended signals isolate easily, because each line passes through its own optocoupler or digital isolator channel, which makes UART, RS-232, and SPI straightforward. RS-485 is routinely isolated as well, and integrated isolated transceivers are readily available. I2C is the awkward case, since SDA is bidirectional on a single wire and open-drain, so isolating it requires purpose-built bidirectional isolators that manage the direction changes without latching. Designers who anticipate an isolation requirement often avoid routing I2C across the barrier at all, placing a local controller on the far side instead.

Implementation Best Practices

Successful serial communication implementation requires attention to both hardware and software considerations:

Hardware Design

Signal integrity: Keep trace lengths short for high-speed protocols. Use ground planes and avoid routing signals near noise sources. Consider impedance matching for very high speeds.

Termination: Apply appropriate termination for the protocol and cable length. RS-485 requires termination resistors; SPI and I2C may benefit from series resistors to reduce reflections.

Level shifting: Use appropriate level shifters when connecting devices with different voltage levels. Ensure shifters support the protocol's signaling characteristics (bidirectional for I2C, high-speed for SPI).

ESD protection: Include transient voltage suppressors on signals exposed to the outside world. This is especially important for RS-232 and RS-485 connections to external equipment.

Software Design

Error handling: Implement timeouts to recover from communication failures. Check for protocol-specific error conditions (NACK in I2C, framing errors in UART).

Buffer management: Size buffers appropriately for expected data rates and processing delays. Consider DMA for high-throughput applications to reduce CPU overhead.

Atomic operations: Use repeated starts in I2C and maintain chip select during multi-byte SPI transactions to ensure operations are not interrupted by other bus traffic.

Configuration management: Store and verify communication parameters. Provide fallback mechanisms if automatic configuration fails.

Testing and Debugging

Use appropriate tools: Logic analyzers with protocol decoders dramatically simplify debugging. Oscilloscopes reveal signal quality issues invisible to protocol analysis.

Start simple: Verify basic communication at low speeds before increasing data rates. Confirm timing parameters and signal levels match specifications.

Document configurations: Record working settings, cable pinouts, and device addresses for future reference and troubleshooting.

Summary

Serial communication protocols provide essential connectivity for embedded systems, each offering distinct advantages suited to specific application requirements. UART's simplicity makes it ideal for debug interfaces and simple device communication. SPI's speed and full-duplex capability serve high-throughput peripheral interfaces, and its multi-lane QSPI variants have become the standard path to external flash memory. I2C's multi-device bus efficiency excels when connecting numerous sensors and low-speed peripherals, with SMBus tightening its guarantees and I3C extending its speed and capability. I2S provides standardized digital audio connectivity, scaling to many channels through TDM. RS-232 bridges to legacy equipment, while RS-485 enables robust communication in industrial environments. Narrower interfaces such as 1-Wire and LIN fill niches where cost and wiring economy dominate.

Selecting the right protocol requires understanding both the technical characteristics and the practical trade-offs involved. Considerations include data rate requirements, number of devices, transmission distance, noise environment, available pins, isolation needs, and system complexity. Often, embedded systems employ multiple protocols simultaneously, using each where its strengths best match the application's needs. A single board might boot from QSPI flash, read sensors over I2C, drive a display over SPI, expose a UART console for debugging, and reach remote equipment over RS-485.

Successful implementation demands attention to both hardware and software aspects: proper signal routing, termination, and level shifting on the hardware side; robust error handling, efficient buffer management, and careful timing on the software side. With thoughtful design and implementation, serial communication protocols provide reliable, efficient data exchange that enables the rich functionality of modern embedded systems.

Related Topics