SPI/I2C Interfaces for SAR & Sigma-Delta ADCs
← Back to:Analog-to-Digital Converters (ADCs)
SPI/I²C on SAR/ΣΔ ADCs is not just a wiring choice: it sets the real data throughput, timing determinism, and noise/isolation risk of the whole measurement chain. Use fixed-length transactions (often DRDY-driven burst/DMA) and interface-aware layout/protection to get predictable, recoverable readout without bus lockups.
What this page solves
This page focuses on the SPI and I²C digital interface layer used by SAR and sigma-delta (ΣΔ) ADCs: the control and data path that moves configuration and samples between an ADC and a controller. The interface choice directly shapes achievable throughput, timing determinism, EMI/noise robustness, and routing/pin cost.
Typical boundary between I²C and SPI
- I²C: low-pin, easy multi-drop routing for sensor nodes and low-to-moderate readout rates where bus overhead is acceptable.
- SPI: higher data bandwidth and more deterministic timing for continuous readout, DRDY-triggered acquisition, and robust industrial wiring practices.
What the content enables
- Quickly decide whether SPI or I²C is appropriate for a target sample rate and word length.
- Identify interface-side bottlenecks (bus overhead, framing, DRDY handling) before committing to hardware.
- Avoid common wiring and robustness mistakes (shared bus conflicts, level compatibility, isolation placement).
Scope note: this page stays at the interface layer (control + data transport). It does not explain ADC architectures in depth, sampling clock jitter theory, JESD/LVDS links, or internal ΣΔ digital filter design.
Interface definitions and how ADCs expose them
ADCs typically expose SPI or I²C as a register-based control plane plus a sample-readout path. Many devices also provide acquisition-side pins (such as CONVST/START and DRDY) that define when a result becomes valid, while SPI/I²C defines how the controller moves configuration and data.
SPI on SAR/ΣΔ ADCs (engineering view)
- 4-wire SPI uses SCLK, MOSI, MISO, and CS (plus optional DRDY). 3-wire variants may share data on a single SDIO pin.
- Mode (CPOL/CPHA) is a compatibility detail. The key is stable timing and a clean return path for SCLK and data.
- Shared-bus requirement: MISO (SDO) must support tri-state or bus isolation to avoid contention when multiple devices share SCLK/MOSI.
I²C on SAR/ΣΔ ADCs (engineering view)
- I²C readout is commonly register-centric: device address + register pointer + data bytes, with ACK and START/STOP overhead.
- Many parts provide ALERT/INT for data-ready or threshold events, reducing polling overhead in low-rate sensor nodes.
- Pull-up strength, bus capacitance, and noise environment often set real-world limits more than the nominal bit rate.
Acquisition-side pins (CONVST/START, DRDY, SYNC) indicate conversion timing and result readiness. SPI/I²C carries the configuration and moves the samples.
Principles: throughput, determinism, and latency
Interface limits are easiest to evaluate with a single, consistent model. The useful data rate is not the raw bus clock. It is the raw bit rate reduced by framing overhead and by whether the device supports continuous streaming reads.
A practical throughput model
Effective throughput ≈ Bus bit rate × Payload ratio × Continuous-read factor
- Bus bit rate: SPI uses SCLK; I²C uses the bit time including protocol phases.
- Payload ratio: fraction of bits that are actual sample data (not command/address/ACK/CRC).
- Continuous-read factor: whether samples can stream in a burst without re-sending setup phases.
What creates overhead (why “bus clock” is not “data rate”)
- SPI overhead: command/address bits, dummy clocks, optional status/CRC, and CS gaps between frames.
- I²C overhead: START/STOP, device address, register pointer, ACK bits, and repeated-start phases for reads.
- Overhead matters most when words are short (16–24 bit) or when frequent register access interrupts streaming.
Interface-side readout latency can be approximated as: DRDY wait + frame transfer time + controller response (ISR/DMA scheduling). Deterministic timing is easier to achieve with fixed-length SPI bursts than with variable-length I²C transactions.
Design: wiring topologies and bus sharing
Bus sharing decisions are usually made to save pins and routing, but the topology also affects contention risk, debug effort, and time alignment between channels. The key difference is whether multiple devices can safely share a return path for data signals without two outputs driving the same wire at the same time.
SPI: shared clock and data, with one hard rule
- SCLK and MOSI can be shared across devices. Each device typically uses a dedicated CS.
- Hard rule: only one device may drive MISO at a time. This requires tri-state SDO, a bus buffer/isolator strategy, or a daisy-chain structure.
- CS decoding can reduce pin count, but adds another timing boundary and a new failure mode during bring-up.
Daisy-chain: fewer chip-selects, more accumulated delay
- A daisy-chain can reduce CS count and enable long burst reads across multiple devices.
- Trade-offs include added frame latency per device, more difficult fault isolation, and stricter assumptions about fixed frame length.
I²C: address planning and controlled fanout
- Multi-drop is natural for I²C, but the address space and device address options set practical limits.
- When addresses conflict or fanout grows, a bus multiplexer or segmented buses keeps behavior predictable.
Signal integrity and noise coupling
On SAR and ΣΔ ADC boards, interface problems are often visible as “analog” issues: unstable codes, sensitivity to cable touch, or performance that changes with SPI clock rate. These symptoms usually come from return-path disruption, ground bounce, and capacitive coupling from fast digital edges into AIN/REF regions.
The three most common coupling paths (interface-layer view)
- Return-path breaks: digital return current detours through sensitive regions, creating ground bounce and shared-impedance coupling.
- Edge-to-node capacitance: SCLK/SDA edges inject charge through parasitic capacitance into AIN/REF copper.
- Over-fast edges: steep transitions increase crosstalk and radiated noise; edge control often fixes issues without reducing sample rate.
Practical routing and edge-control rules
- Keep SCLK/CS and I²C lines away from AIN/REF areas; avoid parallel runs next to high-impedance analog traces.
- Preserve a continuous reference under fast digital lines; partitioning should guide return currents, not cut them off.
- Series resistors near the driver reduce edge rate and ringing, lowering both crosstalk and EMI risk.
- Do not cross plane splits with SCLK/SDA/SCL; a split forces the return path to loop through unintended regions.
I²C is especially sensitive to pull-up strength and bus capacitance: weak pull-ups slow rising edges and shrink timing margin, while strong pull-ups sharpen edges and increase both EMI and static current. Long cables often need segmentation or lower bus speed.
Isolation, level shifting, and protection
Industrial and multi-board systems often need clear domain boundaries: different ground potentials, long cables, hot-plug exposure, or mixed logic voltages (1.8 V, 3.3 V). A robust interface stack separates protection, edge damping, and domain translation so that the ADC always sees valid logic levels and predictable timing.
Isolation differences: SPI vs I²C
- SPI isolation is typically straightforward: multiple unidirectional lines (SCLK/MOSI/CS) plus return lines (MISO and often DRDY).
- I²C isolation is more constrained: the bus is open-drain and bidirectional, so the isolator must preserve two-way behavior across domains.
- Status pins (DRDY/ALERT) should cross the same boundary as the bus when timing alignment and fault signaling are required across domains.
Logic levels and IOVDD
- Many ADCs support a dedicated IOVDD pin so the digital interface level tracks the controller domain (1.8 V or 3.3 V) without changing the analog supply.
- When IOVDD does not match, a level shifter or an isolator with level translation maintains valid VIH/VIL thresholds while limiting edge overshoot.
Protection on digital interfaces should be placed at the domain entry points (connector/cable side) and kept electrically compatible with the bus: excessive capacitance or aggressive clamping can deform edges and create new failures.
Firmware and FPGA readout patterns
Interface performance depends on the readout pattern as much as on the bus clock. A stable acquisition loop typically uses a data-ready signal to trigger fixed-length reads, then stores samples into a buffer with minimal CPU involvement.
Common readout modes (interface-layer view)
- Polling: useful for bring-up and low rates, but increases jitter and CPU load as SPS rises.
- DRDY interrupt + burst read: stable timing near DRDY and lower CPU occupancy than polling.
- DMA burst: the most effective way to use the available bus throughput and reduce software bottlenecks.
Deterministic sampling readout with DRDY
- Use DRDY as the acquisition trigger and keep the response path short (ISR starts DMA or initiates a burst).
- Prefer a fixed frame length (fixed bytes per sample or per block) to keep transaction time predictable.
- Use ring buffers and watermarks so rare stalls do not cascade into missed samples.
Multi-device alignment at the interface layer is easiest when each DRDY event maps to a fixed-length burst. Optional per-sample metadata (status/CRC and timestamp) should preserve a constant frame size when deterministic timing is required.
Engineering checklist (do the interface right once)
A clean SPI/I²C interface is achieved by getting four layers right: defining the real requirements, implementing schematic-level boundaries, preserving return paths in layout, and verifying behavior under worst-case conditions.
- Spec: target SPS, word length, burst/stream mode, CRC/status, max cable length, isolation rating (if used).
- Hardware: IOVDD and logic levels, pull-up range (I²C), series resistors, ESD placement, DRDY/ALERT routing.
- Layout: continuous return paths, no split crossings, keep digital edges away from AIN/REF, controlled connector entry.
- Validation: logic-analyzer captures, edge/duty checks, CRC/NACK/timeout handling, fault injection and recovery.
Applications: where SPI/I²C truly shapes the system
This section only covers scenarios where the interface directly determines pin-count, wiring topology, determinism, and isolation strategy. Detailed domain applications (motor FOC, ultrasound, imaging, etc.) belong in their dedicated application pages.
1) Industrial sensor node (I²C)
- Why bus matters: two wires plus addressing enables low-pin, multi-device sensor nodes.
- Typical pattern: register configuration + periodic reads; ALERT/INT can reduce polling.
- Common failure: pull-up/capacitance trade-offs (slow edges vs EMI/current) and long-cable margin loss.
2) PLC / compact DAQ (SPI + DRDY)
- Why bus matters: fixed-length SPI bursts provide predictable transfer time and higher usable throughput.
- Typical pattern: DRDY interrupt → SPI burst (often DMA) → ring buffer.
- Common failure: missing DRDY, variable frame lengths, or poor edge control causing analog-domain sensitivity.
3) Isolated measurement module (SPI + isolator)
- Why bus matters: multiple unidirectional lines map cleanly into digital isolator channels; DRDY is often isolated too.
- Typical pattern: protection + edge damping → isolator/level-translation → ADC SPI readout.
- Common failure: wrong boundary placement for protection/return currents, or using components that add excessive bus capacitance.
IC selection logic: interface fields to ask suppliers
The most expensive interface mistakes come from missing a small datasheet detail: a non-streaming read path, a non-tri-stated SDO, an unclear timeout behavior, or mismatched I/O thresholds. The checklist below focuses only on interface-related fields that impact throughput, determinism, bus sharing, isolation, and debug.
Throughput (usable data rate)
- SPI max SCLK: max supported clock and any duty-cycle limits.
- Continuous read / streaming: fixed-length burst mode without repeated register-pointer steps.
- Frame structure: command/address/dummy/status bytes; whether it can be held constant.
- CRC: presence, length, what bytes are covered, and how errors are reported.
Pins and bus sharing (board-level wiring decisions)
- DRDY/BUSY: dedicated data-ready output and timing relationship to the output word.
- SDO tri-state: required for multi-device SPI MISO sharing (or define a safe alternative topology).
- Daisy-chain support: whether chain mode exists and what it changes (frame length, latency, debug).
- I²C addressing: number of selectable addresses and rules for multi-drop nodes.
Robustness (lockups, recovery, and observability)
- Status / fault latching: sticky flags, overflow indicators, and error bits readable over the bus.
- Timeout behavior: what happens on incomplete frames, missing clocks, or invalid commands.
- I²C clock stretching: supported or not; any constraints in high-load scenarios.
- ALERT/INT: optional pin for I²C devices to reduce polling and accelerate fault response.
Isolation and I/O levels (domain boundaries)
- IOVDD range: supported digital I/O supply range and allowed sequencing constraints.
- Input thresholds: VIH/VIL compatibility with 1.8 V vs 3.3 V controllers; any 5 V tolerance (if needed).
- Isolation compatibility: SPI line count (plus DRDY) vs I²C bidirectional open-drain behavior.
- Edge guidance: suggested series resistors / pull-up ranges / cable-length notes (interface only).
Debuggability (bring-up speed)
- Timing diagrams: clear burst/read examples with DRDY, frame length, and error cases.
- ID / sanity reads: device ID, known-default registers, and readback guarantees.
- Diagnostic modes: loopback/pattern/status checks (interface-visible features).
Example part numbers (interface reference only)
These examples help map interface expectations to real devices. Datasheets must be treated as the source of truth for final selection.
- I²C ΣΔ / precision nodes: ADS1115, ADS1219, MCP3421
- I²C SAR / low-pin sampling: AD7992, ADS7828, MCP3221
- SPI SAR / deterministic readout: AD7685
- SPI ΣΔ / DRDY-driven systems: AD7172-2, ADS131M04
Request a Quote
FAQs: SPI/I²C interface bring-up, throughput, and robustness
These FAQs close the long-tail questions that typically appear during ADC interface selection and bring-up: required bus speed, common “all-zeros/all-ones” failures, multi-device wiring rules, I²C pull-up trade-offs, isolation/level-shifting pitfalls, and practical verification/recovery patterns.
How to back-calculate the required SPI SCLK from sampling rate (SPS)?
Required SCLK is determined by bits per delivered sample and the transaction overhead, not just the ADC resolution.
- Step 1: compute frame_bits = data_bits + status_bits + CRC_bits + dummy_bits + command/address bits (if any).
- Step 2: include inter-frame gaps (CS high time, turn-around, MCU overhead) as an efficiency factor η (0–1).
- Rule of thumb: SCLK ≥ SPS × frame_bits ÷ η. Use a conservative η (0.6–0.8) unless proven by DMA burst captures.
- Best practice: keep a fixed-length burst per DRDY event so η is stable and latency jitter stays low.
Why does SPI read back all 0xFFFF or 0x0000? What to check first?
Constant 0xFFFF/0x0000 is usually a digital interface not actually delivering valid ADC data.
- MISO state: confirm SDO is driven (not tri-stated) during CS low; add a temporary pull-down/up to detect floating lines.
- CS framing: verify CS polarity, minimum low/high time, and that the intended device is selected.
- SPI mode: confirm CPOL/CPHA and bit order match the datasheet timing diagram.
- Conversion readiness: ensure conversion is started and the read occurs after DRDY/BUSY indicates data is ready.
- IO levels: confirm IOVDD and VIH/VIL compatibility; mismatched thresholds often look like “always same value”.
What conditions must be met to share MISO across multiple ADCs on SPI?
Sharing MISO is safe only when exactly one device drives the line at a time.
- SDO tri-state support: each ADC must tri-state its SDO when CS is deasserted (datasheet explicitly states this).
- CS timing discipline: avoid overlapping CS assertions; enforce guard time if needed.
- Signal integrity: add small series resistors near each SDO driver if ringing/crosstalk is observed.
- Isolation/level shifting: ensure the shared MISO path is in the same I/O domain and does not get “re-driven” by translators.
How much extra latency does daisy-chain add, and when should it be avoided?
Daisy-chain often increases latency because the chain shifts more bits per read.
- Bit growth: total shifted bits ≈ N × frame_bits for N devices (plus any command/CRC overhead).
- Transfer delay: additional time ≈ (N−1) × frame_bits / SCLK (order-of-magnitude estimate).
- Avoid daisy-chain when strict per-device determinism is needed, when debugging must be fast, or when wiring allows clean multi-CS routing.
- Use daisy-chain when CS scarcity dominates and the chain read fits comfortably inside the DRDY-to-buffer budget.
Can I²C 400 kHz support 1 kSPS or 10 kSPS? How to estimate?
I²C throughput is limited by protocol overhead (START/ADDR/ACK/STOP/RESTART) and by rise-time margin.
- Step 1: count bits per sample transaction: addressing + register pointer + repeated start + read bytes + ACKs + stop.
- Step 2: compute ideal payload rate: 400 kbit/s ÷ bits_per_sample_transaction.
- Step 3: apply efficiency (0.5–0.8 typical) to account for firmware gaps and clock stretching.
- Practical note: 1 kSPS is often feasible for small word sizes; 10 kSPS may require higher I²C mode, fewer overhead bytes, or a different interface.
What are the most common reasons for intermittent I²C NACK?
- Rise-time too slow: pull-ups too weak for the bus capacitance → edges violate timing at higher speed.
- Noise/coupling: SDA/SCL routed through noisy regions or long cables without segmentation → bit errors → NACK.
- Address conflicts: two devices respond to the same address or address pins are mis-strapped.
- Clock stretching edge case: controller does not tolerate stretching behavior (or the device stretches longer than expected).
- Power/IO domain sequencing: a device is not fully powered or I/O pins are back-powered through pull-ups.
How to choose I²C pull-up resistors (cable length, capacitance, speed trade-off)?
Pull-ups must be strong enough for rise time, but not so strong that EMI and static current become excessive.
- Rise-time estimate: use an RC approximation for the bus: t_r ≈ 0.85 × R_pullup × C_bus.
- Upper bound on R: choose R so the rise time meets the I²C mode requirement at the real C_bus (including cable and ESD capacitance).
- Lower bound on R: ensure sink current at logic-low is within device limits and acceptable power/EMI.
- Long cables: reduce speed, segment the bus, or use buffers/muxes rather than forcing extremely strong pull-ups.
What happens if SPI/I²C lines run close to AIN/REF, and what is the fastest fix?
Fast digital edges can couple into sensitive analog nodes through shared return impedance and parasitic capacitance, causing code noise, drift-like behavior, or sensitivity to SPI clock changes.
- Fastest fix 1: add series resistors near the driver to slow edges and reduce ringing.
- Fastest fix 2: reroute SCLK/SDA/SCL away from AIN/REF zones and keep a continuous return reference under the lines.
- Fastest fix 3: avoid crossing plane splits; split crossings force return-current detours through sensitive regions.
When isolating SPI, should DRDY/SYNC lines be isolated as well?
- Isolate DRDY when deterministic readout is required across the boundary (DRDY triggers ISR/DMA on the controller side).
- Optional when the system reads at a slow, non-critical rate and can tolerate polling-based readiness checks.
- SYNC/START/CONVST should cross the same boundary if it directly controls when conversions occur relative to readout timing.
- Practical rule: any signal that defines “when to read” should remain consistent across isolation domains.
What are the easiest failure points in 1.8 V ↔ 3.3 V level shifting for SPI/I²C?
- Wrong thresholds: VIH/VIL incompatibility when IOVDD is not configured correctly.
- I²C bidirectional behavior: using a unidirectional translator on an open-drain bus breaks arbitration and ACK/NACK behavior.
- Added capacitance: level shifters and protection parts can increase C_bus, slowing I²C edges and shrinking margin.
- Power sequencing: back-powering through pull-ups or IO pins can lock devices into undefined states.
What should be checked on a logic analyzer capture for SPI/I²C ADC bring-up?
- SPI mode: clock idle level, sampling edge, and bit order; confirm against the datasheet timing diagram.
- CS discipline: CS boundaries align with the intended frame; no extra clocks outside CS low.
- DRDY relationship: read starts after DRDY, and frame length is constant across samples.
- I²C edges: rise time quality, repeated-start correctness, ACK/NACK placement, and clock stretching events.
- Worst-case: capture at maximum SPS/traffic; marginal systems often “work” only at low rate.
How to design timeouts/CRC/retry so the system does not “hang”?
A robust interface treats errors as recoverable events with bounded time, not as blocking waits.
- Bound every wait: DRDY wait, bus transfer, and post-read validation all need explicit deadlines.
- Classify errors: CRC mismatch, NACK, timeout, unexpected status bit → each has a defined recovery action.
- Retry with limits: cap retries; escalate to bus reset (I²C recovery clocks) or ADC soft reset, then reconfigure.
- Keep frame constant: deterministic fixed-length reads reduce corner-case behaviors and simplify watchdog logic.
- Log counters: track CRC/NACK/timeout counters; these reveal margin erosion before catastrophic failure.
