嵌入式Linux--LinuxIIO子系统驱动开发:核心框架与实战

一、IIO子系统的定位与价值

IIO（Industrial I/O）是Linux内核专为ADC/DAC类传感器打造的标准化驱动框架，核心解决工业、消费电子、物联网及可穿戴设备中，大量传感器（加速度计、陀螺仪、温度传感器、压力传感器等）的驱动管理难题。这类传感器本质依赖ADC/DAC完成模拟量与数字量的转换，通过I2C/SPI接口与SoC通信，IIO子系统通过统一抽象，提供标准化的sysfs接口、触发采集与缓冲区机制，彻底告别零散驱动开发模式，大幅降低驱动开发与维护成本。

二、核心数据结构：驱动开发的基石

IIO驱动开发的核心是围绕三大结构体展开，分别完成设备抽象、硬件操作与通道定义，三者协同实现硬件与内核、用户空间的标准化交互。

1. struct iio_dev：IIO设备总控制器

iio_dev是IIO设备的全局抽象，承载设备的核心属性与运行状态，是驱动初始化与注册的核心载体。

- 关键成员解析

- modes与currentmode：定义设备支持的工作模式，常用模式包括直接模式（INDIO_DIRECT_MODE，适用于常规sysfs读写）、硬件/软件触发缓冲模式（INDIO_BUFFER_TRIGGERED/INDIO_BUFFER_SOFTWARE，适配高速批量采集），currentmode记录当前生效的模式。

- channels与num_channels：通道数组指针与通道总数，直接关联传感器的采集维度，例如六轴传感器的7个通道（三轴加速度、三轴陀螺仪、一路温度）需在此明确配置。

- info：指向iio_info结构体的指针，是硬件操作的核心回调入口，用户空间对设备的所有操作最终都会映射到该结构体定义的函数中。

- name：设备名称，是sysfs中设备节点的命名依据，需保证唯一性与辨识度。

- trig与pollfunc：触发器与触发时执行的回调函数，用于缓冲区模式下的批量数据采集控制。

- scan_mask相关成员：控制缓冲区采集的通道选择，available_scan_masks定义可选通道掩码，active_scan_mask记录已开启的通道，决定哪些通道的数据会进入缓冲区。

- chrdev：内核自动创建的字符设备，无需开发者手动实现cdev注册，简化字符设备开发流程。

- 生命周期管理

- 内存分配：优先使用devm_iio_device_alloc函数，该函数基于设备模型（devm）实现内存自动释放，避免手动管理内存泄漏风险。若需手动分配，可使用iio_device_alloc，同时支持绑定私有数据结构体（如自定义的传感器设备结构体），通过iio_priv函数可快速获取私有数据首地址。

- 注册与注销：初始化完成iio_dev的所有成员后，调用iio_device_register将设备注册到内核；设备移除时，调用iio_device_unregister完成注销。使用devm分配的内存无需手动释放，内核会在设备卸载时自动回收。

2. struct iio_info：硬件操作核心接口

iio_info是连接用户空间与硬件的核心桥梁，定义了用户空间读写设备数据的关键回调函数，是驱动开发的核心实现部分。

- 核心回调函数

- read_raw：实现硬件数据的读取逻辑，是用户空间获取传感器数据的核心入口。该函数通过mask参数区分读取的数据类型，例如读取原始ADC采样值（IIO_CHAN_INFO_RAW）、量程分辨率（IIO_CHAN_INFO_SCALE）、零点偏移（IIO_CHAN_INFO_OFFSET）等。函数需根据通道的寄存器地址，通过I2C/SPI接口读取硬件数据，并填充val与val2参数返回。

- write_raw：实现硬件配置的写入逻辑，用于用户空间配置传感器参数，例如修改量程、采样率、零点校准等。同样通过mask参数区分配置类型，根据val与val2参数完成硬件寄存器的写入操作。

- write_raw_get_fmt：定义用户空间写入数据时的格式，决定val与val2的组合规则，例如IIO_VAL_INT_PLUS_MICRO表示小数部分放大1e6倍，将1.00236转换为val=1、val2=2360，适配内核无浮点数传递的限制。

- 数据传递规则：内核与用户空间无法直接传递浮点数，因此采用val（整数部分）与val2（小数部分放大后的整数）组合的方式传递数值，放大倍数由write_raw_get_fmt指定，需严格遵循内核定义的格式规范，确保数据转换的准确性。

3. struct iio_chan_spec：通道定义与抽象

通道是IIO子系统的核心概念，一个传感器的每个采集维度对应一个通道，例如三轴加速度计的X、Y、Z轴各为一个通道，iio_chan_spec用于精准定义每个通道的属性与硬件关联。

- 关键成员解析

- type：通道类型，通过iio_chan_type枚举指定，涵盖电压、电流、加速度、角速度、温度、压力等主流传感器类型，需与传感器的实际采集物理量完全匹配，例如加速度计对应IIO_ACCEL，陀螺仪对应IIO_ANGL_VEL。

- modified与channel2：用于区分同类型下的多个通道，modified置1时，channel2使用通道修饰符（如IIO_MOD_X、IIO_MOD_Y、IIO_MOD_Z），分别对应X、Y、Z轴，确保每个通道的唯一性，同时决定sysfs通道文件的命名规则。

- address：通道对应的硬件寄存器起始地址，是read_raw函数读取硬件数据的直接依据，需严格匹配传感器数据手册中的寄存器地址。

- scan_type：定义数据在缓冲区中的存储格式，需与传感器ADC输出格式完全一致，包含符号位（sign，'s'表示有符号、'u'表示无符号）、有效位数（realbits）、存储位数（storagebits）、右移位数（shift）和大小端模式（endianness，IIO_BE为大端、IIO_LE为小端），若配置错误会导致数据解析错乱。

- info_mask_：控制sysfs属性的生成与共享规则，是优化sysfs接口的关键。

info_mask_separate表示属性为通道独有，例如各轴的原始值，每个通道生成独立文件；info_mask_shared_by_type表示同类型通道共享属性，例如三轴加速度计的量程，仅生成一个共享文件；info_mask_shared_by_all表示所有通道全局共享属性，例如全局采样率。

- 通道配置示例：以ICM20608的X轴加速度通道为例，需配置type为IIO_ACCEL，modified置1且channel2为IIO_MOD_X，address指向X轴数据寄存器，scan_type匹配传感器的16位大端数据格式，info_mask_separate使能IIO_CHAN_INFO_RAW（生成独立原始值文件），info_mask_shared_by_type使能IIO_CHAN_INFO_SCALE（三轴共享量程文件）。

三、IIO驱动开发完整流程

IIO驱动开发遵循标准化流程，从硬件适配到设备注册，每一步都依托核心结构体实现，确保驱动的规范性与兼容性。

1. 硬件底层适配：先实现I2C/SPI的寄存器读写函数，封装为统一的硬件操作接口，为上层回调函数提供基础支持，确保硬件通信的稳定性。

2. 定义私有数据结构：创建自定义传感器设备结构体，包含I2C/SPI客户端指针、硬件配置参数、寄存器缓存等，用于存储设备专属信息，通过iio_priv与iio_dev绑定。

3. 通道数组配置：基于传感器的采集维度，逐个定义iio_chan_spec通道，精准配置type、modified、channel2、address、scan_type及info_mask_，确保每个通道的属性与硬件完全匹配。

4. 实现iio_info回调：核心开发环节，编写read_raw与write_raw函数，在read_raw中根据mask判断数据类型，通过硬件接口读取寄存器并组装val与val2；在write_raw中根据mask完成硬件参数配置，确保用户空间的操作能正确映射到硬件行为。

5. 初始化与注册iio_dev：使用devm_iio_device_alloc分配iio_dev并绑定私有数据，填充name、modes、channels、num_channels、info等核心成员，调用iio_device_register完成设备注册，内核会自动创建sysfs接口与字符设备。

6. 绑定总线驱动框架：基于硬件接口类型（I2C/SPI），编写probe函数完成上述初始化流程，配置设备树匹配规则，实现驱动与硬件设备的自动绑定，同时实现remove函数处理设备卸载逻辑。

四、用户空间使用与调试

驱动加载完成后，用户可通过sysfs接口直接访问传感器数据，无需编写复杂应用程序，极大简化了调试流程。

- 直接模式（sysfs接口）：通过/sys/bus/iio/devices/iio:deviceX目录下的文件操作实现数据读写，例如cat in_accel_x_raw读取X轴加速度原始值，cat in_accel_scale读取量程分辨率，真实物理值可通过原始值乘以量程计算得出；通过echo命令向对应文件写入参数，可配置传感器量程、采样率等。

- 缓冲区模式（高速采集）：适用于高速批量采集场景，需先配置scan_mask使能目标通道，设置触发器（定时器或外部中断），通过/dev/iio:deviceX字符设备读取缓冲区中的批量数据，满足高速采样需求。

五、开发常见踩坑与规避策略

1. scan_type配置错误：大小端与位数配置与硬件不匹配会导致数据解析错乱，需严格对照传感器数据手册，多数MEMS传感器采用大端存储，需将endianness设为IIO_BE。

2. info_mask_使用不当：同类型通道未使用info_mask_shared_by_type会导致sysfs生成大量重复文件，增加系统冗余，需根据属性共享特性合理选择掩码类型。

3. mask判断遗漏：read_raw与write_raw中必须通过switch语句区分所有支持的mask，未处理的mask需返回-EINVAL，避免内核崩溃或数据异常。

4. 内存管理风险：非devm分配的iio_dev需在remove函数中先调用iio_device_unregister注销，再调用iio_device_free释放内存，防止内存泄漏；优先使用devm接口规避手动管理风险。

5. shift参数遗漏：当ADC有效位数小于存储位数时（如12位ADC用16位存储），需配置shift右移位数，否则数据精度会出错，需严格匹配硬件规格。

六、适用与不适用场景

- 适用场景：多路ADC采集芯片、MEMS六轴/九轴传感器、DAC模拟输出芯片、工业压力/流量变送器、光照传感器等带模数转换的外设，尤其适合需要标准化接口、批量采集的场景。

- 不适用场景：简单单路GPIO模拟ADC、一次性读写的简易传感器，此类场景直接使用字符设备驱动更轻量化，无需引入IIO框架的额外开销。

七、总结

IIO子系统通过iio_dev、iio_info、iio_chan_spec三大核心结构体，构建了标准化、模块化的传感器驱动开发框架，核心逻辑是抽象设备、定义通道、实现硬件操作回调。

开发者只需聚焦硬件适配与回调函数实现，无需重复造轮子，即可快速完成ADC/DAC类传感器的驱动开发。掌握通道配置、数据格式转换、sysfs接口生成的核心逻辑，结合标准化开发流程与避坑策略，就能高效开发出稳定可靠的IIO驱动。