In resource-constrained systems, including microcontrollers, single-board computers, and compact FPGA platforms, real-time signal acquisition means that the acquisition path consistently meets a defined timing deadline. That requirement covers latency, jitter, and sustained throughput on every critical sample or data block, not just on average. Meeting those deadlines with limited RAM, CPU cycles, and I/O bandwidth takes deliberate architecture, including DMA-driven data transfer, double buffering, careful clock design, and platform choices that balance flexibility against deterministic behavior.
Many guides frame data acquisition primarily in terms of resolution and channel count, but that framing becomes incomplete once timing is a functional requirement. This technical deep dive is intended for engineers working with kilobytes to megabytes of local memory, clocks ranging from a few megahertz to hundreds of megahertz, and latency budgets that may be measured in microseconds. We will work through the acquisition path, platform choices, and design trade-offs, then examine how the same ideas apply to Digilent hardware.
What “Resource-Constrained” and “Real-Time” Actually Mean
Both terms are used loosely, so it helps to define them clearly. A resource-constrained system might have only a few kilobytes or megabytes of RAM rather than gigabytes. Its processing resources, memory bandwidth, storage, and power budget may all be limited. Some systems run bare-metal firmware, while others use an RTOS or embedded operating system.
Real-time means the system must produce a required result within a defined amount of time. Missing a deadline does not simply make the system slower. Depending on the application, it can cause data loss, reduce control-loop stability, or violate a system requirement. That is what separates real-time data acquisition from acquisition that is merely fast on average.
The Three Real-Time Requirements: Latency, Jitter, and Throughput
Real-time acquisition rests on three measurable requirements, and a complete design must account for all three. Latency is the time between a defined input event and the point when the resulting sample or processed output becomes available to its consumer. In a tight control loop, that time may be measured in microseconds.
Jitter is the variation in timing between repeated events. It is important to distinguish sample-clock jitter from processing or transport jitter. Sample-clock jitter changes the actual sampling instant and can degrade measurement quality, while processing-latency jitter makes completion times less predictable and can cause missed deadlines.
Throughput is the sustained amount of data the complete pipeline can move and process without overflowing a buffer or dropping samples. A system can be fast on average without being real-time. A high average data rate does not compensate for occasional stalls that overflow a buffer or miss a required response deadline.
The Four Core Building Blocks
An analog real-time data acquisition system generally relies on four interconnected building blocks. Because they form a pipeline, the full system is limited by whichever stage cannot keep up.
The ADC
The analog-to-digital converter establishes the sampling rate, resolution, input range, bandwidth, and conversion behavior available to the rest of the system. The appropriate ADC architecture depends on the signal and application. SAR converters are widely used for general-purpose and precision acquisition, sigma-delta converters are common in lower-bandwidth precision measurements, and pipeline converters are frequently used for higher-speed signals.
Conversion latency matters alongside sample rate. Some converters include digital filtering or pipeline stages that add delay between the physical sampling event and the availability of the output code. If the application has a tight latency budget, that delay can make an otherwise attractive converter unsuitable. Define the worst-case timing requirement before selecting a converter based only on its resolution or headline sample rate.
DMA (Direct Memory Access)
DMA is often one of the most important architectural tools in sustained real-time acquisition. A DMA controller moves samples between a peripheral and memory without requiring the CPU to execute an instruction for every transferred value. This allows the processor to work on one block of data while the DMA controller receives the next block.
Without DMA, frequent interrupts or polling can consume a large part of the processor’s execution time. The practical limit depends on the processor, peripheral, memory system, interrupt overhead, and amount of processing required for each sample. DMA does not eliminate every source of jitter, but it reduces CPU involvement in routine transfers and makes sustained block-based acquisition easier to design.
Double Buffering (Ping-Pong Buffers)
Double buffering, also called ping-pong buffering, uses two memory buffers that alternate roles. While DMA fills buffer A with new samples, the CPU or processing engine works on the samples already stored in buffer B. When buffer A is full, the buffers exchange roles. This arrangement allows acquisition and processing to overlap, and it can continue without data loss as long as each completed buffer is processed before that buffer is needed again.
Buffer size creates an important trade-off. A larger buffer gives the processor more time between buffer-complete events and can improve transfer efficiency, but it may increase block-processing latency. A smaller buffer reduces the time before data becomes available, but it creates more frequent interrupts or task wakeups. The correct buffer size is therefore tied to the application’s deadline, processing time, transfer overhead, and available memory.
Interrupt Handling and RTOS Scheduling
The interrupt and scheduling strategy determines whether the buffer design remains reliable under load. On a microcontroller, an interrupt handler commonly responds to a DMA half-complete or buffer-complete event. The handler should usually do the minimum necessary work: record which buffer is ready, notify the processing code, and return. Lengthy signal processing inside the interrupt handler increases interrupt latency for other peripherals and makes worst-case timing harder to predict.
With an RTOS such as FreeRTOS or Zephyr, the interrupt handler can signal a dedicated processing task. The task can then run at a defined priority outside the interrupt context. A bare-metal design may instead use a main-loop state machine or work queue. An RTOS is not automatically required, but it can make task prioritization and timing behavior easier to manage when the application contains multiple concurrent activities.
Platform Choices for Real-Time Signal Acquisition
Real-time data acquisition can run on hardware ranging from inexpensive microcontrollers to FPGA-based systems designed for high-speed parallel processing. The goal is not to choose the most powerful platform. It is to choose a platform that meets the required sample rate, latency, channel count, processing load, and development budget with enough margin for worst-case conditions.
MCU-Only Designs: STM32, ESP32, and RP2040
An MCU-only design is often the lowest-cost and most portable starting point. It is well suited to embedded sensors, condition monitoring, motor control, and lower-channel-count acquisition. However, internal ADC capabilities vary significantly between MCU families.
The RP2040, for example, includes a 12-bit ADC with a 500 kS/s rate, while its DMA controller can transfer peripheral data into its multi-bank SRAM. Some STM32H7 devices include 16-bit SAR ADCs. Depending on the device, resolution setting, and ADC configuration, STM32H7 ADCs can operate at multi-megasample-per-second rates, with higher rates possible through interleaving.
The ESP32 provides convenient integrated ADC functionality, but accurate voltage measurement requires attention to calibration and noise. The actual ADC reference voltage can vary between devices, so calibration may be necessary to improve results.
These examples show why an MCU tier should not be defined by one universal resolution or sample-rate ceiling. The decision depends on the specific MCU, ADC configuration, number of active channels, memory bandwidth, and processing workload. For many low-channel-count projects, an MCU remains the right place to start. Move to a more complex platform when the measured timing and throughput requirements demand it.
MCU Plus an External ADC
Adding an external ADC allows the design to move beyond the resolution, input range, channel count, or analog performance available from the MCU’s internal converter. The ADC may connect through SPI, a parallel interface, or another synchronous digital link. This is a common architecture for sensor hubs, embedded instruments, and custom data loggers.
An external ADC can improve measurement performance, but it also increases hardware-design complexity. Clock integrity, power-supply noise, grounding, reference-voltage quality, input protection, and PCB layout can all affect the final result. The MCU must also be able to receive the converter’s data rate. A fast ADC is not useful if the serial interface, DMA controller, memory bus, or processing code cannot sustain the output stream.
FPGA Plus External ADC: Eclypse Z7 and Zmods
When an MCU-based architecture cannot meet the required parallelism, timing consistency, or interface bandwidth, an FPGA or FPGA-based SoC becomes a strong option. The Eclypse Z7 combines a Zynq-7020 SoC, a dual-core Arm Cortex-A9 processing system, programmable logic, 1 GB of DDR3L memory, Gigabit Ethernet, and two SYZYGY-compatible Zmod ports.
For analog input, it can be paired with a Zmod Scope 1410-105, which provides two channels at 14-bit resolution and 105 MS/s. The Zmod Scope 1410-125 provides two channels at 12-bit resolution and 125 MS/s. The Zmod Digitizer 1430-125 provides two 14-bit channels at 125 MS/s and includes features intended for higher-speed digitizer applications.
On a Zynq-based system, the programmable logic can implement the capture interface, triggering, preprocessing, and AXI streaming path. The processing system can then manage higher-level processing, storage, networking, or a user interface. This architecture provides a bridge between conventional microcontroller acquisition and larger custom instrumentation systems.
MPSoC and RFSoC Platforms
Zynq UltraScale+ MPSoC devices combine multicore Arm processors with programmable logic and dedicated DSP resources. RFSoC devices extend that architecture by integrating high-speed RF data converters into the silicon.
These platforms can support demanding communications, radar, imaging, and advanced research applications, but RFSoC and MPSoC should not be treated as interchangeable terms. A standard MPSoC development board does not automatically include integrated GSPS analog converters. The appropriate platform depends on whether the design needs additional processing capacity, faster digital interfaces, external high-speed converters, or converters integrated directly into the device.
Common Real-Time Acquisition Design Patterns
Several implementation patterns appear repeatedly in embedded acquisition systems. Each one distributes capture, buffering, transfer, and processing differently.
Pattern 1: MCU Plus Ethernet Double Buffering
Two buffers reside in MCU memory. DMA fills one buffer from the ADC while the application packages the previously completed buffer for transmission over Ethernet. This pattern works well when the embedded device is responsible primarily for capture and forwarding, while a host computer performs visualization, storage, or heavier analysis.
The sustainable data rate depends on the MCU, Ethernet controller, protocol stack, packet size, memory architecture, and whether the network shares resources with the acquisition path.
Pattern 2: MCU Plus Edge Inference
In this pattern, the MCU buffers and preprocesses the input signal before sending selected features or data windows to a machine-learning model running on the device. Potential applications include vibration classification, keyword spotting, and condition monitoring.
The important design question is not only how long inference takes on average. The complete system must guarantee that acquisition continues while preprocessing and inference run, or provide enough buffering to cover the worst-case processing interval.
Pattern 3: FPGA Plus Arm With Shared DDR
On a Zynq SoC, programmable logic can capture samples and move data through an AXI-based path into shared DDR memory. Software on the Arm processor can then access buffered data for operations such as FFTs, decimation, protocol framing, visualization, or network transfer. Because the FPGA fabric and processor are integrated into the same SoC, the design can avoid moving every sample through an external host interface before processing begins.
The achievable sample rate still depends on the converter, FPGA interface, AXI configuration, memory bandwidth, processing load, and output path. Shared DDR provides substantial capacity, but memory contention and cache coherency must be included in the design.
Common Trade-Offs and Design Decisions
A real-time system cannot optimize every dimension independently. Most designs involve trade-offs among latency, throughput, memory, power, and development complexity.
Determinism Versus Throughput
Systems optimized for high sustained throughput often process data in larger blocks because batching can reduce software and transfer overhead. Larger blocks, however, may increase the time before the first sample in the block is processed. Instrumentation and recording applications often prioritize sustained throughput and long captures, while closed-loop control applications usually place more emphasis on bounded latency and timing consistency.
Deciding which behavior matters most early in the design prevents later conflicts between the buffering strategy and the actual application requirement.
On-Chip Memory Versus External DDR
On-chip SRAM provides low-latency access and avoids many of the arbitration and refresh considerations associated with external memory. Its capacity is limited, however, especially when several buffers, processing stages, and communication stacks must share it.
External DDR provides much larger capture windows and can be shared between programmable logic and processor subsystems. The trade-off is a more complex memory path with arbitration, caching, and variable access latency. Use on-chip memory when the required processing window fits comfortably. Use external memory when the application needs longer captures, larger processing blocks, or shared access across multiple processing engines.
Power Versus Performance
MCUs can be highly efficient in low-duty-cycle and battery-powered applications. FPGA and SoC platforms offer more parallel processing and interface bandwidth but generally require a larger power and thermal budget.
The actual difference depends heavily on the selected device, clock rates, active logic, peripheral load, and duty cycle. Power should therefore be measured using the real design rather than estimated only from the platform category. A battery-powered sensor and a fixed laboratory instrument may arrive at very different platform choices even when their sample-rate requirements are similar.
Building a Real-Time Acquisition Pipeline With Digilent Hardware
Digilent hardware can support several levels of data acquisition, depending on the required sample rate, timing model, host involvement, and processing architecture.
Entry Level: MCC USB DAQ Plus Host PC
The MCC USB-1608FS-Plus provides eight simultaneous analog inputs, 16-bit resolution, a sample rate of up to 100 kS/s per channel, and a 400 kS/s aggregate rate. Digilent provides driver support for environments that include LabVIEW, MATLAB, Linux, and Python.
Because acquisition is buffered by the device while a host PC manages the application, this tier is well suited to data logging, laboratory measurements, and soft real-time monitoring. It should not automatically be treated as a hard real-time control platform. Host operating-system scheduling, USB transfer behavior, driver buffering, and application design all influence when data becomes available to the host application.
Choose this tier when a host PC is acceptable, simultaneous sampling matters, and the required acquisition rate fits within the device’s specifications.
Mid-Tier: Eclypse Z7 Plus Zmod Scope or Digitizer
For higher sample rates or applications that benefit from hardware-defined triggering and preprocessing, the Eclypse Z7 can be paired with a compatible Zmod. The Zmod Scope 1410-105 provides two 14-bit channels at 105 MS/s, while the Zmod Digitizer 1430-125 provides two 14-bit channels at 125 MS/s.
The FPGA fabric can implement the converter interface, trigger logic, filtering, decimation, and DMA path. The Arm processor can manage software-controlled processing, storage, and network communication. Digilent’s Eclypse Z7 resource center includes hardware documentation, Linux support, and example projects. The Eclypse Z7 DDR Streaming Demo captures data from the Zmod Scope 1410-105 and writes the results to a file under PetaLinux or to standard output in the bare-metal workflow.
That example is a useful reference point, but it should not be treated as proof that every custom Eclypse configuration will automatically sustain an arbitrary continuous DDR or Ethernet streaming rate. The custom design still needs to be tested against its complete data path.
Higher-End Processing and Expansion: Genesys ZU
The Genesys ZU is available with Zynq UltraScale+ 3EG or 5EV devices. It includes a quad-core Cortex-A53 application processor, dual-core Cortex-R5 real-time processor, programmable logic, 4 GB of DDR4, and Zmod and FMC expansion interfaces. The 5EV variant adds more programmable logic resources, GTH transceivers, video-codec capability, and 10 Gigabit SFP+ support.
Genesys ZU can provide more processing capacity and expansion flexibility than the Eclypse Z7, but it is not an integrated GSPS data acquisition device. A high-speed analog acquisition system still requires a compatible external ADC or acquisition module, an appropriate expansion interface, and a validated data path.
Choose this tier when the application needs additional processing resources, high-speed expansion, more memory, or more complex connectivity, not simply because the required sample rate exceeds a single numerical threshold.
Analog Signal Conditioning
All of these architectures assume that the signal presented to the ADC is within the converter’s electrical and bandwidth limits. In practice, many sensors require signal conditioning before conversion. That may include amplification, attenuation, level shifting, filtering, input protection, impedance matching, or isolation.
An anti-aliasing filter is especially important when input content can extend above the frequencies that the selected sample rate can represent. Without adequate filtering, out-of-band signal energy can fold into the measured frequency range and cannot be removed reliably through downstream digital processing. The ADC input network must also be designed around the converter’s input impedance, acquisition time, full-scale range, and reference requirements.
Frequently Asked Questions
Why Is DMA Important for Real-Time Acquisition?
DMA reduces the amount of CPU work required to move each sample between a peripheral and memory. Instead of entering an interrupt or executing polling code for every value, the CPU can process completed data blocks while the DMA controller transfers new samples in the background.
That does not make the system automatically real-time. The buffers, memory bus, processing time, interrupt priorities, and output path still have to meet the application’s worst-case timing requirements.
What Is the Difference Between Hard and Soft Real-Time?
In a hard real-time system, missing a defined deadline is considered a system failure. Safety-critical control systems are common examples. In a soft real-time system, occasional deadline misses reduce quality or performance but do not necessarily cause total system failure. Buffered monitoring, multimedia, and many data-logging applications fall closer to this category.
The classification depends on the consequence of missing the deadline, not simply on whether the hardware is fast.
What Is Better for Real-Time Acquisition: FPGA or MCU?
There is no single sample-rate or latency threshold that applies to every design. An MCU is often the better choice when the converter interface, DMA controller, memory bandwidth, and CPU can meet the requirement with sufficient margin. It usually provides a faster and simpler development workflow.
An FPGA becomes more attractive when the design needs high-speed parallel interfaces, many synchronized channels, custom digital timing, precise hardware triggering, or substantial sample-by-sample processing. A platform such as the Eclypse Z7 splits the workload between programmable logic and Arm processors on the same device. Time-critical acquisition and preprocessing can run in the FPGA fabric, while software manages configuration, communication, and higher-level analysis.
If the requirements are not yet clear, begin by calculating the full data rate and latency budget. Choose the simplest platform that can meet those requirements under worst-case conditions.
