PrajnaEdge
An interactive engineering platform where complex concepts become experiences—through visual explorations, simulations, and practical understanding.
PrajnaEdge Navigation Tree
Embedded Systems Tree
On the Horizon
PravahaPath
Something new is taking shape.

Articles & Write-ups

Exploring how systems evolve from hardware to integration.

Sort:

Edge AI Demonstrations

Deploying neural networks and intelligent decision loops on raw silicon targets.

Sort:
Interaction

The Roads Not Often Travelled

How constraints, cost, and physical boundaries spawned the specialized cousins of UART, SPI, I2C, and CAN.

USARTQSPISMBusLINOne-WireSerial Protocols

1. USART: The Synchronous Bridge

In our exploration of UART, we discovered that asynchronous communication is a delicate timing contract. Without a shared clock wire, nodes must rely on internal oscillators, oversampling clocks, and framing bits (Start/Stop) to synchronize. This contract is simple but costly: clock drift limits speeds, and framing adds a 20% protocol overhead on every byte.

But what if we added a clock line back to UART? That hybrid is the Universal Synchronous Asynchronous Receiver Transmitter (USART).

When configured in synchronous mode, USART transmits a dedicated clock signal alongside the data line. Instead of oversampling and searching for start bits, the receiver simply samples the data wire on the clock edges. This eliminates clock drift issues, allowing speeds comparable to SPI while retaining UART's simple frame packaging. Yet, despite being present on almost every modern microcontroller, synchronous USART is rarely used. If an engineer is willing to route a clock line, the simplicity of UART is lost; and if they have a clock line, they almost always prefer the faster shift register architecture of SPI or the multi-slave addressing of I2C. USART remains a bridge not often crossed, operating quietly in asynchronous UART mode on most developer desks.

USART Timing Diagram showing Synchronous Clock CK and Data TX Alignment vs Asynchronous UART
USART Timing Diagram showing Synchronous Clock CK and Data TX Alignment vs Asynchronous UART

2. QSPI: SPI on Steroids

SPI achieved extreme throughput by sharing a clock, but it remained limited by its physical architecture: a single MOSI (Master Out Slave In) and MISO (Master In Slave Out) line. As microcontrollers shrank, board designers began moving flash memory outside the MCU package to external chips. This created a critical bottleneck: loading bootloader code and assets over a single MOSI/MISO line was too slow, stalling system startup.

The solution was Quad SPI (QSPI). Instead of keeping data lines unidirectional, QSPI converts MOSI, MISO, and two additional pins into four bidirectional data channels (IO0 through IO3). In a single clock cycle, the controller reads or writes four bits of data instead of one.

By leveraging this quad-width bus and Dual Data Rate (DDR) clocking—sampling on both rising and falling edges—QSPI increases throughput up to eightfold. This massive bandwidth allows modern microcontrollers to execute code directly from external flash memory (Execute-in-Place, or XiP), making external memory feel as responsive as internal SRAM.

Standard SPI (4 wires) vs Quad SPI (6 wires showing IO0-IO3 bidirectional lines)
Standard SPI (4 wires) vs Quad SPI (6 wires showing IO0-IO3 bidirectional lines)

3. SMBus: Stricter Rules for a Shared Conversation

I2C gave us a clean, shared bus using open-drain logic and software addressing. But I2C's flexibility was also its weakness. It lacked strict timeouts, standardized voltage thresholds, and error checking. If a slave device crashed or held SCL low (clock stretching) to process data, the entire bus could freeze indefinitely. On a PC motherboard, a single hanging temperature sensor could lock up the system.

To address this, Intel defined the System Management Bus (SMBus) in 1995. SMBus is electrically compatible with I2C but enforces a strict set of rules:

1. Bus Timeout: If SCL is held low for more than 35ms, all devices must reset their internal interface controllers and release the bus, preventing permanent lockups. 2. Packet Error Checking (PEC): Appends a Cyclic Redundancy Check (CRC-8) byte to ensure data integrity, critical for battery charging controllers. 3. SMBALERT# Line: Adds an optional interrupt wire, allowing slave devices to notify the master of events (like battery over-temperature) immediately, avoiding the need for continuous polling.

SMBus turned the cooperative conversation of I2C into a reliable, deterministic diagnostic bus for power management.

SMBus Topology showing pull-ups, SCL, SDA, and the SMBALERT# alert line
SMBus Topology showing pull-ups, SCL, SDA, and the SMBALERT# alert line

4. LIN: The Economical Sub-Bus

CAN bus solved the problem of high-noise automotive environments using differential signaling and bitwise arbitration. But this reliability came with a high cost: CAN requires a dedicated controller IP, a transceiver chip, and two twisted copper wires. Putting a CAN node in every car door, side mirror, seat motor, and window lifter would drive up vehicle costs and weight.

This economic constraint gave birth to the Local Interconnect Network (LIN) bus.

LIN is a single-wire, master-slave sub-bus. It operates at low speeds (up to 20 kbps) using standard, low-cost UART frames. It runs on a single wire pulled up to 12V (battery voltage), eliminating the need for differential transceivers. Instead of complex CAN controllers, LIN runs on cheap 8-bit microcontrollers. In a car, a single CAN-enabled body controller acts as the LIN Master, managing a cluster of LIN slaves (doors, locks, mirrors) and bridging their diagnostic info back to the primary CAN backbone, saving copper, weight, and silicon cost.

LIN single-wire network topology with Master node, slave modules, and 12V pull-up
LIN single-wire network topology with Master node, slave modules, and 12V pull-up

5. One-Wire: Minimalism in Copper

If LIN reduced the bus to a single wire plus power and ground, Dallas Semiconductor's 1-Wire protocol went even further. It reduced the entire bus—power, clock, and data—to a single copper conductor (DQ) and a ground return.

1-Wire devices use parasitic power. Inside each slave device is a small capacitor. When the master lets the DQ line float HIGH, the slave harvests energy from the wire to charge its capacitor. When the master pulls the line LOW to transmit data, the slave runs off the stored capacitor charge.

With no clock wire, timing is critical. Communication is divided into precise time slots (e.g. 15µs to 60µs) where master and slave pull the line low for varying durations to represent 0s and 1s. Every 1-Wire device is factory-programmed with a unique, immutable 64-bit registration ID. This allows a master to communicate with dozens of sensors (like the DS18B20 digital thermometer) sharing the same single wire run, with zero manual address configuration. 1-Wire represents the ultimate realization of hardware minimalism.

1-Wire bus topology showing master, parasitic power slaves, DQ wire, and pull-up
1-Wire bus topology showing master, parasitic power slaves, DQ wire, and pull-up

6. Summary and Comparison

The history of embedded communication was never a straight line. UART, SPI, I²C, and CAN became the major highways of the interaction layer because they solved the most common problems. Yet engineers continually carved smaller paths whenever unique constraints appeared.

Some of these protocols remained specialized niches; others became industry standards. All of them remind us that embedded engineering evolves through physical and economic constraints rather than the pursuit of theoretical perfection.

Core Communication Protocols
Protocol Style Typical Speed Topology Strength Common Use
UART Asynchronous, Full-Duplex 9.6 - 115.2 kbps Point-to-Point (2 wires) Simple, no clock line needed Debug logs, simple telemetry
SPI Synchronous, Full-Duplex 10 - 50+ Mbps Master-Slave (4+ wires) Extreme throughput, simple hardware SD cards, displays, fast sensors
I²C Synchronous, Half-Duplex 100 - 400 kbps Shared Bus (2 wires) Low pin count, hardware addressing EEPROMs, onboard sensors
CAN Asynchronous, Half-Duplex 125 kbps - 1 Mbps Shared Bus (2 wires) Noise immunity, arbitration Automotive, industrial control
Unexpected Cousins
Protocol Parent Protocol Why It Exists (Constraint) Typical Use
USART UART Adds synchronous clock line to eliminate clock drift at high speed High-speed serial links, synchronous peripherals
QSPI SPI Repurposes pins into 4 bidirectional channels to increase flash throughput Booting from external flash (Execute-in-Place)
SMBus I²C Enforces strict timeouts (35ms) and alert line to prevent bus lockups Smart battery packs, PC motherboard system health
LIN CAN Sub-bus reducing cost using single-wire 12V and basic UART logic Car mirrors, windows, door lock body modules
One-Wire Custom Ultimate pin reduction, merging data and power on a single wire Temperature sensor networks (DS18B20), electronic keys

The Evolution of Constraint

Every protocol we study is a snapshot of a compromise made under a specific set of physical, financial, and temporal boundaries.

As systems developers, our task is not to find a single perfect protocol, but to understand which compromise aligns best with the constraints of the world we are building.

Engineering does not look for perfect answers. It builds paths through constraints.
System Tree Node Interaction
ABOUT PRAJNAEDGE

Engineering concepts you don't just read — you experience.

PrajnaEdge is an interactive engineering platform where complex concepts become experiences—through visual explorations, simulations, and practical understanding.

WHY PRAJNAEDGE EXISTS

Engineering is often taught as a collection of isolated concepts.

A processor here.
A protocol there.
An operating system somewhere else.

But real systems are built by connecting these layers.

PrajnaEdge exists to make those connections visible.

Each exploration starts with a question, builds an intuition, and gradually reveals the system underneath through visualizations, simulations, practical scenarios, and connections between concepts.

HOW PRAJNAEDGE WORKS

PrajnaEdge is designed around exploration rather than passive reading.

Concepts are introduced progressively, visualized when they benefit from seeing them, and brought to life through interactive EdgeCases and simulations where appropriate.

The goal is not simply to explain what a system does, but to help the learner understand why it works the way it does.

CREATOR PROFILE

Devaharsha Meesarapu

Embedded Systems • Firmware • Edge AI

I am the engineer behind the design, development, and content of PrajnaEdge. I build low-level systems where code directly controls hardware, bridging the gap between register-level silicon behavior and intelligent edge decision loops.

View Resume →

ABOUT ME

I am an Embedded Firmware Engineer focused on developing software for resource-constrained systems. My experience spans bare-metal firmware, device drivers, microcontroller peripherals, and communication protocols, working across the boundary between hardware and software.

My work has involved microcontroller-based systems, real-time behaviour, hardware interfaces, and communication technologies such as CAN, CAN FD, UART, SPI, and I²C. I am particularly interested in understanding systems from the lowest level upward—from registers and peripherals to intelligent edge systems.

ENGINEERING PHILOSOPHY

Engineering is not just about writing code; it is about managing constraints, timings, and physical hardware characteristics. True mastery of complex systems comes from understanding the interactions across different layers of the stack.

This conviction is why I built PrajnaEdge—to bridge the gap between conceptual theory and direct, register-level physical reality.

CONNECT

LinkedIn → GitHub →

Interactive Career Journey

Let's Connect
Interested in embedded systems, AI, or building something meaningful? I'd love to hear from you.
Open to collaborations, research, and interesting engineering conversations.
Help Improve PrajnaEdge
Found something to improve? I'd love to hear your thoughts.

Bare Metal

Software that runs directly on hardware without an operating system.

Applications
Operating Systems
YOU ARE HERE
Bare Metal
Processor
Hardware

"Every embedded application begins long before main()."

Operating Systems

An Operating System manages hardware and software resources so complex applications can work efficiently.

Applications
YOU ARE HERE
Operating Systems
Bare Metal
Processor
Hardware

"When one loop is no longer enough to carry the burden."

Support PrajnaEdge

PrajnaEdge is an independent education platform built to make knowledge freely accessible.

If you find PrajnaEdge useful, you can support its continued development.

Your support helps fund the time, tools, infrastructure, and experimentation that go into building and maintaining PrajnaEdge.

Select Region
Select Amount
Select an amount to support PrajnaEdge.