Modern data acquisition projects rarely start and end on the same platform. Engineers often begin by evaluating sensors in simple environments, then evolve their systems across different compute platforms and software stacks as requirements grow toward visualization, analytics, and deployment. The challenge is not acquiring data once but is difficult maintaining a consistent workflow as the system evolves across operating systems, compute platforms, and vendors.
ADI DataX™ addresses this challenge as ADI’s open, unified software enablement framework for data acquisition. DataX is not a single tool, but an umbrella for ADI’s drivers, middleware, and ecosystem integrations that together provide a flexible and consistent data acquisition stack across heterogeneous environments. These stack components allow developers to reuse the same data path and tools while scaling complexity only where needed, keeping integration effort under control as projects move from evaluation to system level software development.
System Overview
At Embedded World 2026, we’re demonstrating that capability in a tangible, system level way. Using different compute platforms and operating systems, the system acquires the same temperature data from identical sensor front ends and visualizes it through a shared workflow. at the edge of the system:
Both boards interface with an EVAL‑CN0391‑ARDZ to read temperature from multiple thermocouples
These heterogeneous nodes connect upstream over 10BASET1L through the AD-RPIT1LPSE-SL and AD-APARDPFW-SL, with a Raspberry Pi running Kuiper Linux 2 acting as the central aggregation and visualization point.
Despite the differences in compute platforms and operating systems , all devices acquire the same sensor data, which can be aggregated, plotted, and analyzed without changing the application-level tooling. By leveraging the flexibility of the .
Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Analog Devices, Inc (ADI) or its subsidiaries. The content is provided for informational purposes only and is not meant to be an endorsement or representation by ADI or any other party. This site may also provide links or references to non-ADI sites and resources. ADI makes no representations, warranties, or other commitments whatsoever about any non-ADI sites or third-party resources that may be referenced, accessible from, or linked to this site.
ADI DataX™ software stack
The demo shows how diverse hardware and OS environments can participate in a single data acquisition system, making it easy to mix, swap, and evolve platforms while keeping the data path and workflow consistent.
How ADI DataX™ Enables Flexible Data Acquisition in this System
In this demo, that flexibility comes from how ADI DataX™ connects embedded devices, operating systems, and application tools into a single, reusable data acquisition workflow.
Open-Source Drivers across Linux, Zephyr, and No-OS
ADI maintains open-source driver repositories as part of the ADI DataX ecosystem, allowing developers to work in the environment that best fits their constraints and experience.
Because these drivers are developed and validated within a common framework, data is exposed in a consistent way even as platforms change. This makes it possible to start with one operating system, evolve to another, or mix environments within the same system. In practice, ADI DataX™ meets developers where they are, while preserving a unified workflow for acquiring and consuming data.
Code in Motion: Standardizing Firmware Builds Across no‑OS Systems:
On the EVAL-ADIN1110 (STM32L) board used in this system, the software environment is intentionally minimal. There is no operating system, no dynamic runtime, and no interactive development layer, only a bare‑metal firmware image that must be built correctly, consistently, and repeatably from day one.
Even with this lightweight footprint, the node is still a first‑class participant in the ADI DataX™‑enabled data acquisition workflow. This is where Code in Motion (CiM) plays a critical role.
Instead of relying on ad‑hoc scripts or board‑specific setup steps, CiM provides a structured and reproducible path to assemble, build, and flash a complete no‑OS firmware image, including toolchains, dependencies, and pinned repository versions.
From Manifest to Binary, One Path to a Flashable Image:
For the EVAL-ADIN1110 (STM32L), CiM is used to generate the final firmware binary (.hex) that gets flashed onto the STM32L device. The key idea is simple: everything required to build that firmware is declared up front.
Instead of following a README with manual steps, CiM relies on a manifest that describes
Which git repositories make up the no‑OS application
Which exact commits or tags to use
Which Arm cross‑compiler is required
How the build system should be invoked to produce a .hex file
Once defined, setting up the entire workspace becomes mechanical and repeatable. In practice, building firmware for the EVAL-ADIN1110 (STM32L) looks like this:
With these steps, CiM:
Clones all required repositories at fixed revisions
Installs the correct toolchain automatically
Generates a standardized Makefile
Produces a ready‑to‑flash firmware image without manual intervention.
To learn more about Code in Motion, including its design principles, workflow, and supported use cases, visit the official CiM page at https://analogdevicesinc.github.io/cim. From there, you can also download the CiM tool, explore available manifests, and access the open‑source code used to build and extend CiM‑based workflows through Analog Devices’ public GitHub repositories.
libIIO & iiod making data location irrelevant
Building on the Linux Industrial I/O (IIO) standard, which defines a common and widely adopted model for interacting with data acquisition devices, flexibility in this system is enabled further by libIIO and the Industrial I/O Daemon (iiod). libIIO provides a standard application API on top of IIO, while iiod extends this model by exposing IIO devices over standard interfaces such as TCP/IP, USB, SPI,.. allowing devices to be accessed locally or across the network using the same programming interface.
In this demo, a version of iiod called tiny-iiod runs on the Zephyr based node, enabling remote access to sensor data without special handling at the application layer.
What this enables is simple but powerful:
Data can be accessed locally or remotely through the same interface
Multiple clients can connect to the same data source simultaneously
Applications do not need to know where the data is generated
As a result, heterogeneous compute platforms behave as parts of a single, distributed data acquisition system, rather than isolated endpoints.
Kuiper Linux and Scopy: From Acquisition to Insight
On the aggregation side, a Raspberry Pi running ADI Kuiper Linux brings the system together. Kuiper Linux provides an ADI DataX™ enabled Linux environment with integrated drivers, networking support, and development tools, making it a natural hub for collecting data from distributed embedded nodes.
Within this environment:
Data from embedded devices arrives through the ADI DataX™ stack without custom integration.
Networking and device support are already in place.
The system is ready for visualization and analysis out of the box.
Building on this, CiM is also being extended to simplify how Kuiper Linux is consumed and adapted. Instead of relying on a fixed distribution, developers can now use a CiM manifest to generate a customized Kuiper image, for example targeting kuiper‑basic‑arm64 for Raspberry Pi.
With Kuiper now available directly as a target in the CiM manifest list, developers can discover, initialize, and build these images using the same workflow already used for other SDKs and projects. With just a few commands, the required components and configuration are assembled into a ready‑to‑use image that can be directly flashed onto the Raspberry Pi.
This makes it easier to tailor the aggregation environment to specific data acquisition needs while keeping the setup reproducible and consistent across different users and systems, extending the same streamlined build experience from project setup all the way to system deployment.
Scopy, included as part of the Kuiper Linux distribution, connects directly to the ADI DataX™ exposed data streams. Without additional setup, it can visualize and log temperature measurements coming from devices running different operating systems. This allows signal chain evaluation and system level visibility to coexist within a single, continuous workflow, rather than requiring separate tools or one-off bridges as the system evolves.
This closes the loop between embedded data acquisition and application level insight, showing how DataX enables systems to grow in complexity without breaking the workflow.
Learn More
To get started with this demo, follow the GitHub documentation for hardware requirements and setup instructions.
To explore additional DataX demos and learn more about the broader DataX framework, visit the DataX Solution Center.
