在嵌入式开发中，采集模拟信号（如温度、电压、压力）是高频需求，而 ADC 和 IIO 是这个流程中两个核心角色。很多开发者调试时会困惑：“我已经有 ADC 芯片了，为什么还要用 IIO？”“IIO 是替代 ADC 吗？”

其实，ADC 是硬件层面的“模拟-数字转换器”，IIO 是软件层面的“工业 I/O 子系统”，两者是“硬件载体”与“软件框架”的依赖关系——IIO 子系统专门为 ADC等模拟器件提供标准化驱动与访问接口，让开发者无需直面复杂硬件细节，就能高效采集模拟信号。

1 ADC 与 IIO 各自负责什么？

要理解两者关系，先明确各自的定位和功能，避免混淆“硬件能力”与“软件封装”。

ADC：模拟信号的“硬件转换器”

ADC（Analog-to-Digital Converter，模数转换器）是实打实的硬件器件（或芯片内置模块），核心使命是将连续变化的模拟信号（如 0~5V 电压）转换成离散的数字信号（如 0~4095 数值），让嵌入式系统能识别和处理。

简单说：ADC 是“干活的硬件”，没有它，模拟信号无法转换成系统能识别的数字信号，采集工作就无从谈起。

IIO（Industrial I/O Subsystem，工业 I/O 子系统）是 Linux 内核中的一套软件框架，专门为ADC、DAC、陀螺仪、加速度计等“混合信号器件”而设计，核心使命是为这些器件提供标准化的驱动模板、数据传输机制和用户空间访问接口。

IIO 的核心价值（软件层面）：

（1）统一驱动规范：不同厂商的 ADC（如 ADS1115、MAX11644），在 IIO 框架下遵循同一套驱动开发标准，避免重复造轮子；

（2）简化用户访问：开发者无需操作底层寄存器，通过 sysfs、字符设备或 DMA 就能读取 ADC 数据（如通过 `/sys/bus/iio/devices/iio:device0/in_voltage0_raw` 直接获取原始值）；

（3）解耦硬件与软件：驱动开发者聚焦硬件适配，应用开发者聚焦数据处理，分工清晰。

简单说：IIO 是“服务 ADC 的软件管家”，它不直接做信号转换，而是让 ADC 硬件的能力更易被系统调用，降低开发门槛。

ADC 与 IIO 的关系，就像 “打印机” 与 “通用打印系统框架”—— 打印机（ADC）是硬件能力载体，没有适配 IIO 框架，系统无法标准化读取 ADC 数据；IIO 提供统一的访问接口，让不同 ADC 的输出标准化，用户无需关心硬件底层寄存器。

如果没有 IIO 框架，开发者要直接操作 ADC 硬件寄存器，会面临 3 大难题：

兼容性差：不同厂商的 ADC 寄存器地址、配置方式完全不同，换一款 ADC 就要重写整套驱动；

复杂度高：需手动处理 ADC 的触发、采样、数据读取等逻辑，还要适配内核版本迭代，调试成本极高；

功能薄弱：无法轻松实现缓冲采集、校准等工业级功能，需自己封装整套机制。

IIO 框架通过“驱动适配+接口封装”，将 ADC 硬件能力转化为系统可调用的服务，流程如下：

驱动开发：开发者基于 IIO 框架，编写 ADC 驱动（适配具体硬件的寄存器配置、触发方式），注册到 IIO 子系统；

设备注册：ADC 驱动加载后，IIO 子系统会在 sysfs 中创建对应的设备节点（如 `iio:device0`），暴露 ADC 的通道、精度、速率等属性；

数据采集：应用程序通过 IIO 提供的接口（sysfs、ioctl、DMA 缓冲），读取 ADC 转换后的数字信号，无需操作底层寄存器；

功能扩展：通过 IIO 框架配置 ADC 的采样速率、触发方式、校准参数，轻松实现工业级采集需求。

但，并不是所有 ADC 都必须用 IIO——

裸机开发（如 STM32 裸机）：无需 IIO，直接操作 ADC 寄存器即可（资源占用少，需求简单）；

Linux 系统开发：尤其是工业场景，优先用 IIO 框架——标准化的驱动和接口能大幅提升开发效率，且适配内核生态，便于功能扩展。

最后补充：IIO 不止支持 ADC，还支持 DAC（数模转换器）、传感器等混合信号器件，但 ADC 是 IIO 框架最核心、最常用的适配对象。

（完）

本人专注 Linux 驱动 & Linux/Android BSP 开发调试，可接外包项目/技术支持/问题定位。有需求或交个朋友可加微信：【Chen_WeChat2025】。