Skip to main content

Talking in Bits: Embedded System Protocols for Sharing Data

(Source: nick/stock.adobe.com; generated with AI)

Communication is something we do from the beginning of life, and yet, it can be challenging to do so effectively, even for the most seasoned communicator. Over many years, humans have developed numerous ways to communicate—verbal, written, pictorial, gestures, and more. Each mode relies on syntax and semantic rules to convey meaning from sender to receiver. Some modes are more efficient, but the goal remains the same: get information from point A to point B.

In this way, modern digital devices are no different from humans. These devices tend to be very “chatty” and communicate with each other in numerous ways as well. An example is a microcontroller polling various sensors or sending packets to be transmitted through a radio. The two components exchange data via well-defined digital communications protocols. When it comes to these protocols, the embedded systems world has a handful of different ones for an engineer to choose from.

This blog examines the most common communications protocols used in embedded systems. Learn the nuances of each particular protocol and understand the overarching structure of embedded communications protocols as a whole.

How Do We Define Digital Communications Protocols?

First, let’s review digital communications protocols. In a nutshell, a digital communications protocol is a set of rules that define how digital components can interface to exchange data. Protocols define numerous aspects of how an electrical signal behaves for the purpose of transmitting ones and zeros so that both sender and receiver can communicate reliably. Some of the essential features of any protocol include:

  • Data Rate: This refers to how fast information can be transmitted, usually measured in bits per second (bps) or megabits per second (Mbps). Higher data rates allow faster communication but may require better signal integrity and more power.
  • Data Encoding: These protocols define how bits are grouped into meaningful data structures:
    • Bytes (e.g., 8 bits)
    • Words (e.g., 16-bit, 32-bit)
    • Frames (e.g., in UART, SPI)
    • Packets (e.g., in networking protocols like TCP/IP or CAN)
  • Line Encoding Schemes: Line encoding schemes refer to how digital bits (ones and zeros) are represented as voltage changes on a physical wire. Options include:
    • Non-Return-to-Zero (NRZ): The signal stays high or low during the entire bit duration. This is efficient and straightforward, but long runs of identical bits can cause synchronization issues.
    • Return-to-Zero (RZ): The signal returns to zero halfway through each bit period. This method is easier for clock recovery but uses more bandwidth.
  • Transmission Modes: These modes define the directionality of data flow between devices. Data flow types include:
    • Simplex: Data flows one way only (e.g., broadcast television).
    • Half-Duplex: Data flows both ways, but only one direction at a time (e.g., walkie-talkies).
    • Full-Duplex: Data flows in both directions simultaneously (e.g., phone calls, UART with separate TX/RX lines).
  • Synchronous vs. Asynchronous Communication: This distinction differentiates between continuous, real-time communication and non-simultaneous communication.
    • Synchronous: Sender and receiver share a common clock. Timing is strict but allows faster and more predictable communication (e.g., SPI, I²C).
    • Asynchronous: The sender and receiver operate independently, using start/stop bits to frame each byte. This requires an agreed-upon baud rate (e.g., UART).
  • Error Detection and Correction: This feature ensures data integrity, especially over noisy or unreliable connections. Digital communications protocols employ the following types of error detection and correction:
    • Parity Bits: Add a single bit to indicate whether the number of ones is odd or even.
    • Checksums: Sum of all data bytes; receiver compares to expected value.
    • Cyclic Redundancy Check (CRC): A more robust form of error detection used in protocols like USB, CAN, and Ethernet.
  • Serial vs. Parallel Transmission: These transmission types define the number of bits and channels involved in transmitting a signal at a given time.
    • Serial Communication: Sends one bit at a time over a wire. Serial is slower than parallel but needs fewer wires, which is ideal for microcontrollers (e.g., UART, SPI, I²C).
    • Parallel Communication: This type of communication sends multiple bits at once across many wires. This is faster but pin-heavy and is used in RAM and display buses.
  • Endianness: This defines the byte order of multi-byte data. Types of endianness include:
    • Big Endian: Most significant byte is sent first.
    • Little Endian: The least significant byte is sent first.
    • Protocols like Modbus and I²S define endianness explicitly. Others (like UART or SPI) do not, so developers must coordinate both ends.
  • Number of Pins Required: Different protocols require different numbers of physical connections:
    • UART: 2 pins (TX, RX)
    • I²C: 2 pins (SDA, SCL)
    • SPI: 4 pins (MOSI, MISO, SCK, SS) + additional chip select (CS) lines for each chip
    • I²S: 3-4 pins (WS, BCLK, SD, optional MCLK)
    • CAN: 2 pins (CAN_H, CAN_L)
    • A lower pin count is important in embedded systems with limited GPIO pins available. Also, while not always explicitly stated, power and ground wires between devices will be needed.
  • Maximum Number of Devices Supported: Each protocol has different capabilities in the maximum number of devices it can support, as shown below.
    • UART: Only two devices (1:1)
    • I²C: Multiple devices (up to 128 with 7-bit addressing)
    • SPI: Multiple devices, limited by the number of select lines
    • CAN: Dozens to hundreds, depending on network size and topology
  • Addressing: Protocols use addressing to specify which device is talking or listening:
    • I²C: Every device has a unique 7- or 10-bit address
    • CAN: Messages are labeled with message IDs, and devices choose whether to act based on the ID
    • UART and SPI: Do not use addressing inherently. In SPI, the master manually selects which device to talk to via a CS line

Popular Digital Communications Protocols for Embedded Systems

Over the past few decades, numerous protocols have been developed to help transfer data between the numerous components that comprise modern embedded systems. Different use cases have led to a variety of protocols optimized for various needs, such as moving large amounts of data quickly or minimizing complexity and overhead for systems that are extremely resource-constrained in terms of memory or clock speed. Below is a breakdown of the most widely used protocols in embedded development, including their characteristics, pros and cons, and typical applications. For a quick overview of these protocols’ features, refer to Table 1.

  • Universal Asynchronous Receiver-Transmitter (UART)
    • Pins: TX (Transmit), RX (Receive)
    • Mode: Asynchronous (no clock line)
    • Speed: Commonly 9600bps to 115200bps, but can go up to several Mbps depending on hardware
    • Use Cases: Serial monitors, GPS modules, Bluetooth®, debugging
    • Pros: Simple, widely supported, low pin count
    • Cons: Only supports 1:1 communication, no inherent addressing
    • Pronounced: You-Art
  • Inter-Integrated Circuit (I²C)
    • Pins: SDA (Data), SCL (Clock)
    • Mode: Synchronous
    • Speed: Standard (100kHz), Fast (400kHz), Fast+ (1MHz), High-Speed (3.4MHz)
    • Use Cases: Sensors, EEPROMs, RTCs, displays (OLED, LCD), multi-sensor arrays
    • Pros: Supports multiple devices (up to 128 with 7-bit addressing), only two wires needed
    • Cons: Slower than SPI, more complex software, limited cable length due to noise sensitivity
    • Pronounced: Eye-Squared-See
  • Serial Peripheral Interface (SPI)
    • Pins: MOSI, MISO, SCK, CS (one per chip device)
    • Mode: Synchronous
    • Speed: Up to tens of Mbps (commonly 1–50Mbps)
    • Use Cases: SD cards, displays (TFT, OLED), high-speed sensors, DACs, ADCs
    • Pros: Very fast, full-duplex, simple protocol
    • Cons: Requires more pins (especially with multiple chips), no built-in addressing
    • Pronounced: Spy
  • 1-Wire
    • Pins: One data line (plus ground)
    • Mode: Synchronous (with timing-based signaling)
    • Speed: ~16kbps (standard), ~142kbps (overdrive mode)
    • Use Cases: Temperature sensors (e.g., DS18B20), iButtons, simple digital ID, and authentication chips
    • Pros: Extremely low pin count, devices powered through data line (parasitic power)
    • Cons: Slower than I²C/SPI, more timing-critical, limited range, and device count
    • Pronounced: One-Wire
  • Controller Area Network (CAN)
    • Pins: CAN_H, CAN_L (differential pair)
    • Mode: Synchronous (multi-master bus)
    • Speed: Up to 1Mbps (CAN 2.0), 5+ Mbps (CAN FD)
    • Use Cases: Automotive electronic control units (ECUs), robotics, industrial automation, and unmanned aerial vehicles (UAVs)
    • Pros: Reliable, robust to noise, supports many nodes, built-in arbitration and prioritization
    • Cons: Requires a transceiver; more complex to implement
    • Pronounced: Can
  • RS-485
    • Pins: A, B (differential pair), optional direction control line
    • Mode: Half-duplex (commonly), multi-point serial
    • Speed: Up to 10Mbps over short distances, lower over long runs
    • Use Cases: Industrial automation, long-distance serial communication, Modbus
    • Pros: Long range (up to 1200 meters), robust against noise, multi-device support
    • Cons: Requires external transceiver and driver logic to manage direction
    • Pronounced: RS-485
  • Inter-IC Sound (I²S)
    • Pins: word select (WS), bit clock (BCLK), serial data (SD),and optional master clock (MCLK)
    • Mode: Synchronous, serial audio data
    • Speed: Depends on sample rate and bit depth (commonly 44.1kHz -192kHz at 16-32 bits)
    • Use Cases: Audio streaming to/from DACs and ADCs, MEMS microphones, audio playback, or processing
    • Pros: Optimized for digital audio, supports stereo and multichannel data
    • Cons: Only supports audio data; not universally available on all MCUs
    • Pronounced: Eye-Squared-Ess

Table 1: A quick glance guide to the various digital communications protocols.

 

Protocol

Pins Needed

Speed

Devices Supported

Use Cases

UART

2

Up to 115200bps

1:1

Debugging, GPS, Bluetooth

I²C

2

~400kHz (standard)

Multiple

Sensors, OLEDs, EEPROM

SPI

4+

~10Mbps+

Multiple (with SS pins)

SD cards, TFT displays

1-Wire

1

~16.3kbps

Multiple

Temperature sensors

CAN

2

~1Mbps

Multiple

Automotive, industrial

RS-485

2

~10Mbps

Multiple

Long-distance industrial

I²S

4

44.1kHz - 192kHz

Multiple

Digital microphones, DACs, and audio processing

Conclusion

Digital communications protocols are the invisible but essential language that allows embedded systems to function. From simple serial links like UART to robust industrial networks like CAN, each protocol has specific strengths, trade-offs, and ideal use cases. To build efficient, reliable systems, it is critical to understand how and why these protocols work, from their physical signaling and data structures to concepts like endianness, error correction, and transmission modes. As embedded devices become more powerful and interconnected, mastering these communications fundamentals gives engineers the tools to design smarter, faster, and more capable hardware that can truly “talk” to the world around it.

About the Author

Michael Parks, P.E. is the owner of Green Shoe Garage, a custom electronics design studio and technology consultancy located in Southern Maryland. He produces the S.T.E.A.M. Power podcast to help raise public awareness of technical and scientific matters. Michael is also a licensed Professional Engineer in the state of Maryland and holds a Master’s degree in systems engineering from Johns Hopkins University.

Profile Photo of Mike Parks