IMX6ULL ADC驱动开发实战：从设备树到IIO子系统全解析

很多做嵌入式Linux的朋友第一次碰到IMX6ULL的ADC驱动开发，第一反应都是：这不就是个简单的寄存器操作？我在单片机上读个电位器那是家常便饭。可真到把设备树、引脚复用、IIO子系统、时钟管理全部串起来的时候，才发现这是个标准的"Linux驱动开发"题目，而不是"ADC采集"题目。这篇文章把我自己从零开始调通IMX6ULL ADC驱动的完整思路、关键代码和踩坑过程整理出来。如果你手里有一块带ADC引脚的IMX6ULL开发板，想接一个电位器或者传感器做电压采集，这篇文章可以直接作为参考路线；如果你只是想搞清楚Linux下ADC驱动到底是怎么工作的，这篇文章也能给你一个完整的脉络。

1. 先说清楚：IMX6ULL的ADC驱动开发难点到底在哪

1.1 12位逐次逼近型ADC的硬件底子

IMX6ULL内部集成的是一个12位逐次逼近型（SAR）ADC，支持8个外部输入通道，从AD1_IN0到AD1_IN7。逐次逼近的工作原理说穿了就是"二分法猜电压"：内部有一个比较器和一个可编程的DAC，先从最高位开始猜，把猜测值转成模拟量跟输入电压比，比完再决定下一位是1还是0，12位就是猜12轮。这个原理本身不难，但落实到芯片上有个关键点——芯片内部有一个采样保持电容，采样瞬间会把输入引脚上的电荷抽走，所以"信号源能不能扛得住这种抽取"直接决定了精度。这一点后面讲输入阻抗时还要展开。

另一个容易被忽略的硬件事实是：这颗ADC并不是IMX6ULL"独有"的IP，它的寄存器风格和驱动框架在早期一系列芯片里都能看到影子。所以你搜资料的时候会看到很多互相矛盾的写法，有人直接说"mainline内核有现成驱动"，有人说"必须自己port BSP驱动"，其实两种说法都对，只是面向的驱动版本不同。

1.2 为什么有人说没现成驱动，有人说有

先说结论：mainline内核里有一个叫vf610-adc的IIO驱动，它的设备树兼容字符串支持fsl,vf610-adc和fsl,imx6ul-adc这类写法，IMX6ULL在不少内核版本上能直接匹配。也就是说，如果你的内核比较新，设备树节点写得对，确实可以做到"配好DTS就能在/sys/bus/iio下面读到数据"，不需要自己写一行驱动代码。

但问题在于，很多开发板上跑的BSP内核是某个厂商定制过的版本，里面的ADC驱动可能是另一套老驱动，设备树节点名、兼容字符串、甚至中断号和时钟名都对不上mainline。再加上有些教程驱动是自研的字符设备驱动，不走IIO框架，直接创建一个/dev/adc节点给你read。这种驱动在某一类板卡上很流行，但你把它搬到另一块板子上，往往要改寄存器操作、改时钟配置，等于重新做一遍移植。

所以IMX6ULL的ADC开发，真正的难点不是"会不会配寄存器"，而是"能不能判断出当前内核环境走哪条路最省力"。我的建议是：先打开你当前内核源码目录，搜一下adc相关的compatible字符串，看看到底有没有驱动能匹配你的芯片，再决定是改DTS还是改驱动。这一步花十分钟，能帮你省掉一整天。

1.3 动手之前先确认的四个事实

第一个事实：板子上ADC引脚到底有没有引出来。很多IMX6ULL核心板把GPIO1_IO01到GPIO1_IO08这些引脚复用给了LCD、JTAG或者网卡，底板上根本找不到ADC测试点。我见过有人折腾半天驱动，最后发现引脚压根没引出到排针，全做了其它功能。

第二个事实：VREF实际接的是多少伏。ADC的满量程就是VREF，如果是3.3V，那么1个LSB就是3300/4096≈0.806mV；如果是2.5V，就是2500/4096≈0.61mV。这个值直接参与电压换算，而且不同板卡差异很大，必须看原理图确认，不能想当然。

第三个事实：你的内核版本和BSP来源。这决定了你是用mainline驱动、厂商BSP驱动，还是要自己写。内核里搜一下，比在论坛问一百遍都准。

第四个事实：目标用途。只是低速读取一个电位器，那轮询就够了；如果是采集音频或者做连续监测，就必须考虑中断、触发缓冲和采样率问题。先想清楚用途，再选技术路线，否则很容易做过头。

2. 硬件侧三件套：引脚复用、参考电压和输入阻抗

2.1 ADC输入通道与引脚复用

IMX6ULL的8个ADC外输通道AD1_IN0到AD1_IN7，对应的是GPIO1_IO01到GPIO1_IO08这8个引脚。但注意，这些引脚在IOMUXC里并不是只有ADC一个功能，它们往往还能做GPIO、UART、JTAG或者其它外设的复用，你必须在设备树里明确把它们配置成"模拟输入"用途，而不是靠默认状态。

这里有个特别容易踩的坑：ADC这类模拟输入在IOMUX里通常没有像UART的ALT模式那么明确的"AD功能"选项。很多BSP的参考例程是把它配成GPIO输入模式，同时关闭上下拉、关闭迟滞，也就是用"高阻抗输入"的状态来让模拟信号进来。我之前第一次配的时候，以为要找一个叫AD1_IN0的mux值，翻遍头文件没找到，后来才明白这个思路。

以最常见的BSP写法为例，设备树里一般是这样的：

&iomuxc { pinctrl_adc1: adc1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0xb0 MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0 >; }; };

后面的0xb0这类pad控制值，在大多数BSP里就是"关闭上下拉、关闭迟滞、设置输入模式"的组合。如果你直接抄一个GPIO输出配置（比如0x10b0这种带驱动的值），ADC读数会受到内部上拉或驱动器的影响，轻则读数偏低，重则完全不对。这块务必对着你BSP里的pad头文件确认。

2.2 参考电压VREF怎么来

VREF是ADC转换的"尺子"，它决定满量程对应的电压。IMX6ULL这颗ADC的参考电压在不同板卡上接法差别很大：有些板卡直接把VREF接到3.3V电源轨，有些用独立的LDO单独供电，还有一些板卡甚至没有把VREF引脚单独引出来，而是内部跟某个电源域绑在一起。

我拿到的这块板子就是VREF接3.3V,但3.3V这一路同时还给SD卡、LED和部分外设供电，结果就是当SD卡读写时，ADC读数会出现周期性的抖动。这种问题如果不知道VREF的来源，会一直以为是驱动里的滤波做得不够。

所以在动手写驱动之前，建议先用万用表实测一下VREF引脚的对地电压，并在不同负载条件下多测几次。如果发现VREF波动明显，就得在硬件上加一级RC滤波，或者干脆在软件里把该电源域的干扰时段避开。VREF不稳时，你在软件上做再多滤波都是治标不治本。

2.3 输入阻抗与信号调理

前面提到的采样保持电容问题，在IMX6ULL上同样存在。ADC采样瞬间会从输入引脚抽取一个电流脉冲，如果信号源阻抗很高，比如直接用了一个1MΩ的电位器，电荷还没来得及补充，采样电容上的电压就已经跌了，最终读数会偏低。

解决思路无非两个方向：一是降低信号源阻抗，在信号源和ADC之间加一个运放跟随器；二是给ADC足够长的采样时间，让采样电容慢慢充到稳定。寄存器里有一个采样周期配置位，有的BSP默认值偏短，接高阻源时读数会明显偏低且不稳定。我测过一个100kΩ电位器直接接ADC，默认采样周期下读数比万用表低了几十毫伏，把采样周期调大之后偏差立刻缩小。

另外一个简单有效的做法是在ADC引脚对地加一个0.1uF的陶瓷电容，形成一个RC低通滤波。这个电容一方面滤高频噪声，另一方面相当于一个电荷池，能在采样瞬间补充一部分电荷。但注意电容太大会让信号响应变慢，如果是动态信号，要权衡取舍。电位器、分压电阻这类静态信号，0.1uF基本是安全的。

3. 寄存器级转换流程：从HC0到R0的一次完整采集

3.1 必须熟悉的六个寄存器

虽然我们最终走IIO框架，但驱动核心始终是寄存器操作。IMX6ULL ADC这一组寄存器说多不多，说少不少，实际开发里最常打交道的就六个。我把它们的偏移和作用整理成一张表：

这里有个特点值得注意：ADC模块内有两套"硬件通道"，也就是HC0/R0和HC1/R1。你可以同时配置两个不同的输入通道，让转换交错进行，也可以把其中一个当成备用通道随时切换。大多数简单驱动只用HC0，但理解HC1的存在对后面做多通道快速切换很有帮助。

3.2 单次转换的完整时序

一次单通道转换的逻辑非常清晰，总共四步：配置、启动、等待、读取。我第一次在单片机上写ADC驱动时是这套流程，到了IMX6ULL上，还是这套流程，只是寄存器名字变了。

第一步，配置CFG寄存器，把ADC时钟分频到合适频率，并设定采样周期。ADC时钟不能超过参考手册给出的上限，否则转换结果不可靠。分频值的计算要看你板子上给ADC供时钟的源头频率，不同BSP里的IPG时钟频率可能不同，必须手算一遍再填。

第二步，往HC0寄存器写入要转换的通道号和启动位。通道号就是0到7，对应AD1_IN0到AD1_IN7。启动位置1后，ADC就会开始一次转换。

第三步，等待HS寄存器里的完成标志。如果开了中断，这一步会变成在中断处理函数里等；没开中断就轮询。轮询时务必加超时保护，不能让驱动在异常情况下死等。

第四步，从R0寄存器读取12位结果。这里要留意结果字段的位宽和位置，不同版本参考手册对结果字段的定义可能有差异，开发时以手头手册为准。我习惯只取低12位，同时屏蔽掉无效的高位。

下面是一段简化版的转换函数，能代表这个流程：

static int imx6ull_adc_convert(struct imx6ull_adc *adc, int ch, int *val) { u32 hc, hs; int timeout = 10000; /* 清状态位 */ writel(0, adc->base + ADC_HS); /* 写通道号和启动位 */ hc = (ch & 0x7) | 0x1; writel(hc, adc->base + ADC_HC0); /* 轮询完成标志COCO0 */ do { hs = readl(adc->base + ADC_HS); if (hs & (1 << 0)) break; } while (--timeout > 0); if (timeout <= 0) return -ETIMEDOUT; *val = readl(adc->base + ADC_R0) & 0xfff; return 0; }

这段代码没用任何花哨技巧，但它是整个驱动的心脏。我在实际调试中遇到的大多数诡异问题，最后都回归到这个函数里：要么是启动位没写对，要么是状态位看错了，要么是超时时间不够。

3.3 校准偏移和增益是怎么回事

SAR型ADC天然存在两种误差：失调误差和增益误差。失调误差表现为输入0V时读数不是0，而是有个固定偏移；增益误差表现为输入满量程时读数不是4095，整体斜率有偏差。IMX6ULL的ADC提供了自动校准机制，就是通过GC寄存器里跟校准相关的控制位，让硬件内部自动测算并修正这两个误差。

校准流程通常是：把校准控制位置1，然后等待GS寄存器里的校准状态位清零。整个过程在probe函数里做一次就够了，不需要每次转换都做。校准完成后，校准结果会体现在偏移校准寄存器和增益校准寄存器里，正常情况下你不需要手动改它们。

我遇到过一台设备在批量生产时，部分板子的ADC读数整体偏低，排查半天发现是产线测试流程里跳过了probe阶段的自校准。所以校准这件事，千万不要觉得"反正影响不大"就省略。尤其当你需要把多个板卡的读数统一对到同一把"尺子"上时，校准是必须的。

4. 驱动代码落地：设备树配置与IIO驱动骨架

4.1 设备树节点和pinctrl填写

不管用现成驱动还是自己写驱动，设备树这一步都绕不开。IMX6ULL的ADC节点在BSP里一般被命名为adc1，寄存器基地址是0x0219c000，中断和时钟属性则因BSP版本而异。下面是一个比较典型的节点写法：

&adc1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_adc1>; clocks = <&clks IMX6UL_CLK_ADC1>; clock-names = "adc"; vref-supply = <&reg_vref_3v3>; status = "okay"; };

这里有两个属性容易出问题。第一个是clocks，如果你用的驱动是mainline的vf610-adc，它会在probe里获取名为"adc"的时钟并启用。DTS里漏配时钟，或者时钟名对不上，probe会直接失败，而且报错信息不一定明显。第二个是vref-supply，如果板子上有专门的VREF稳压器，这个属性用来关联它，驱动可以通过regulator框架读取参考电压值来计算scale。没有这个regulator节点时，驱动就必须在代码里写死一个电压值。

pinctrl部分我在前面已经给了示例，再强调一遍：ADC引脚配置的关键是"高阻抗输入"，宁可少配一个无关属性，也不能配错成带上下拉的输出模式。如果你的设备树里adc1节点没有pinctrl也能启动，别惊讶，有些BSP把引脚状态默认设成了模拟输入。

4.2 probe阶段要做的事

自己写IIO驱动时，probe函数的任务可以归纳为四步：映射寄存器、使能时钟、做自校准、注册IIO设备。这里用platform驱动加devm资源管理的写法最省心，出错时资源自动释放，不容易泄漏。

static int imx6ull_adc_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct imx6ull_adc *adc; struct iio_dev *indio_dev; struct resource *res; indio_dev = devm_iio_device_alloc(dev, sizeof(*adc)); if (!indio_dev) return -ENOMEM; adc = iio_priv(indio_dev); adc->dev = dev; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); adc->base = devm_ioremap_resource(dev, res); if (IS_ERR(adc->base)) return PTR_ERR(adc->base); adc->clk = devm_clk_get(dev, "adc"); if (IS_ERR(adc->clk)) return PTR_ERR(adc->clk); clk_prepare_enable(adc->clk); /* 上电后做一次自校准 */ imx6ull_adc_calibrate(adc); indio_dev->name = "imx6ull-adc"; indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->info = &imx6ull_adc_info; indio_dev->channels = imx6ull_adc_channels; indio_dev->num_channels = ARRAY_SIZE(imx6ull_adc_channels); return devm_iio_device_register(dev, indio_dev); }

校准函数也很直接，就是把校准位置1，然后等状态位清零：

static void imx6ull_adc_calibrate(struct imx6ull_adc *adc) { u32 gc = readl(adc->base + ADC_GC); gc |= 0x1; /* CAL */ writel(gc, adc->base + ADC_GC); while (readl(adc->base + ADC_GS) & 0x1) /* CALU */ cpu_relax(); }

如果你发现校准一直不结束，先查时钟是否真的起来了，再查ADC模块的时钟是否超上限。时钟没使能的情况下，寄存器能读但转换和校准都不会动，这是最经典的"读寄存器全是0但就是不工作"场景。

4.3 read_raw的两种实现：轮询与中断

IIO框架下，用户态读数据最终都会走到iio_info结构体里的read_raw回调。回调里核心就是调用前面写的转换函数。区别在于转换函数内部是轮询等待还是中断等待。

轮询模式实现简单，在read_raw里直接调用转换函数就行了，适合慢速采集场景。中断模式则需要额外把中断号通过platform_get_irq拿到，在probe里request_irq，中断处理函数里标志完成并用complete唤醒等待的read_raw。代码量多一截，但处理器不用空转等待。

这两种方式怎么选？我的经验是：如果采集频率只有几十赫兹以下，轮询完全够用；如果要做音频级别或者需要精确控制采样时刻，走中断加IIO触发缓冲更合理。对大多数开发板上的电位器、光敏电阻、电池电压监测来说，轮询是最简单可靠的。

IIO通道的描述也要定义好，否则用户态看到的节点名和属性名都是错的：

#define IMX6ULL_ADC_CHANNEL(idx) \ { \ .type = IIO_VOLTAGE, \ .indexed = 1, \ .channel = idx, \ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \ BIT(IIO_CHAN_INFO_SCALE), \ .datasheet_name = "AD1_IN" #idx, \ } static const struct iio_chan_spec imx6ull_adc_channels[] = { IMX6ULL_ADC_CHANNEL(0), IMX6ULL_ADC_CHANNEL(1), IMX6ULL_ADC_CHANNEL(2), IMX6ULL_ADC_CHANNEL(3), IMX6ULL_ADC_CHANNEL(4), IMX6ULL_ADC_CHANNEL(5), IMX6ULL_ADC_CHANNEL(6), IMX6ULL_ADC_CHANNEL(7), };

read_raw里要分别处理RAW和SCALE两种请求：

static int imx6ull_adc_read_raw(struct iio_dev *indio_dev, struct iio_chan_spec const *chan, int *val, int *val2, long mask) { struct imx6ull_adc *adc = iio_priv(indio_dev); switch (mask) { case IIO_CHAN_INFO_RAW: return imx6ull_adc_convert(adc, chan->channel, val) ? : IIO_VAL_INT; case IIO_CHAN_INFO_SCALE: *val = 0; *val2 = adc->vref_mv * 1000000 / 4096; return IIO_VAL_INT_PLUS_MICRO; } return -EINVAL; }

5. 用户态数据读取：换算公式、滤波和连续采样

5.1 raw与scale的关系

驱动注册成功后，系统里会出现/sys/bus/iio/devices/iio:device0目录，下面有一堆in_voltageN_raw和in_voltageN_scale文件。raw就是原始读数，scale是每个LSB对应的电压值，单位是mV。最终电压就是两者相乘：

电压(mV) = raw × scale

比如我在板子上实测：

root@board:~# cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw 2015 root@board:~# cat /sys/bus/iio/devices/iio:device0/in_voltage0_scale 0.805664

那么当前电压就是2015×0.805664≈1623mV，也就是1.623V左右。如果你看到scale打印的是一个整数，比如805，那说明驱动返回的是另一种格式，计算时要自己除以1000，换算前先确认一下格式比盲目套公式靠谱。

应用层如果要用C代码循环读取，千万别每次打开关闭文件，开销太大。正确做法是把文件描述符打开后，每次用pread读取，既能随意指定偏移，又不会因为多线程读取互相干扰。IIO的sysfs节点每次read都会触发一次新的转换，所以读的频率就是你实际采样的频率。

5.2 数据抖动怎么处理

ADC读数抖动是再正常不过的事，尤其是最后两位。12位分辨率下，如果VREF是3.3V，1个LSB只有0.8mV，电源纹波、周围电磁干扰、信号线长度都会在最后几位上体现出来。

处理抖动分硬件和软件两条线。硬件上，我前面提到的RC滤波电容是最廉价有效的方案；信号线尽量短，远离PWM线和开关电源；必要的时候用屏蔽线。软件上，最常见的做法是多次采样取平均，比如连续采16次去掉最大最小值再平均，能把大部分随机噪声压下去。IIO本身支持在硬件上配置平均次数，但如果你用的是现成驱动，不一定暴露了这个配置项，那就直接在应用层做更灵活。

还要注意一个特殊现象：如果读数不是随机抖动，而是呈现规律的周期性波动，比如每隔一段固定时间就跳一次，那大概率不是热噪声，而是系统里某个周期事件在干扰VREF或者引脚。最常见的就是开关电源的PWM周期、LED扫描周期、SD卡读写等。遇到这种情况，先查硬件耦合路径，不要一味加滤波。

5.3 多通道轮流采样的坑

如果需要采集多个通道，最直接的思路就是应用层轮流读in_voltage1_raw、in_voltage2_raw。但要注意，如果驱动内部没有加互斥锁，两个线程同时发起转换就可能出现通道串扰：A线程启动通道0的转换，B线程把HC0改成了通道1，结果A读到的数据其实是通道1的。

自己在驱动里加一个mutex，把转换函数的启动到读取包在锁里，是最稳妥的做法。IMX6ULL的HC0/HC1双通道机制本身可以缓解这个问题，比如固定HC0跑通道0，HC1跑通道1，两个结果互不覆盖，但实际使用中，大部分简单驱动并不会利用这一点，而是靠锁保证原子性。

另外，多通道切换时还要留意每个通道之间是否需要延时。如果前一个通道是高阻信号源，采样电容里残余的电荷会影响下一个通道的第一次采样结果，可以先丢弃第一次数据，或者在每次启动转换前插入一个最小间隔。我调试多通道时发现，第一个通道读数总是略偏，后来在应用层把每通道第一次采样结果扔掉，数据立刻正常了。

6. 实测踩坑记录：读数异常的完整排查思路

6.1 固定读0或者满量程

我最开始调这块板子时，电位器怎么拧，读到的都是0。第一反应是驱动问题，查了通道号、寄存器配置，都没错。后来用万用表直接量ADC引脚，发现引脚电压确实在变，但读数始终是0，于是怀疑引脚被内部下拉。

问题果然出在pinctrl上。我当时抄了一份BSP例程的pad配置，那个值带了内部下拉，等于在信号源和地之间接了一个几十到上百kΩ的电阻。电位器本身阻值又比较高，分压之后ADC引脚上的电压被严重拉低，读数自然接近0。换成0xb0这个高阻输入配置之后，问题立刻消失。固定读满量程4095也是类似思路：要么引脚被上拉，要么输入电压真的高于VREF，要么VREF本身没接好导致ADC参考电压异常。

遇到固定读0或满量程，我的排查顺序是：先万用表测引脚电压，确认硬件信号是正常的；再检查pinctrl的上下拉配置；最后检查通道选择和VREF。这个顺序能过滤掉大部分低级问题。

6.2 采样值跳变的真实原因比想象中复杂

一次读数在800到1000之间来回跳，而且跳变毫无规律，这是我遇到的第二个比较头疼的问题。当时我以为是电源噪声，给VREF加电容、给ADC引脚加电容，效果都不明显。后来灵机一动，拿示波器去看ADC引脚的波形，才发现引脚上叠加了一个很高频率的振铃。

这个振铃的来源是信号线。我用了大概20厘米长的杜邦线把电位器连到开发板引脚上，线本身在天线一样接收周围的电磁干扰，再加上分布电感，信号在引脚处产生了振铃。把线换成尽量短的屏蔽线，并且在引脚对地加0.1uF电容后，跳动范围从几百个LSB降到了两三个LSB。这个案例给我的教训是：模拟信号过长的杜邦线就是噪声天线，采集精度要求高时，长线方案本身就该被否决。

软件上我也做了配合，应用层做了一次中值滤波加均值滤波。先取5次采样排序取中值，再连续取几个中值做平均，最终的读数非常稳定。这种方式对于传感器缓慢变化的场景很实用，代价是响应速度变慢，但绝大多数应用都能接受。

6.3 一次转换超时的排查过程

最折磨人的一次问题，是驱动probe完全正常，IIO设备也注册了，但一读raw节点就卡住，最后超时返回错误。这种"设备在但不工作"的现象，比直接报错难排查得多。

我当时的排查链路是这样的：第一步，用devmem工具手动读寄存器，确认设备树里的寄存器基地址对不对；结果能读到，说明映射没问题。第二步，检查中断是否触发。我改了设备树，加了interrupts属性，中断号是从BSP头文件里抄的。手动触发一次转换，用cat /proc/interrupts看中断计数，发现中断从来没来过，于是怀疑中断号配错。第三步，改用轮询方式读状态位，发现轮询也超时——这就说明问题根本不在中断，而是转换压根没完成。第四步，回头看时钟。我在DTS里配了clocks属性，但驱动里没有对ADC时钟做分频配置，默认条件下ADC时钟超过上限，转换一直处于异常状态。把分频值按参考手册重新计算填进去之后，转换立刻正常了。

这个案例给我的最大收获是：遇到"设备注册成功但不工作"，按"寄存器映射→中断→时钟"这个顺序排查，基本能覆盖90%的原因。而且一定要用好devmem和/proc/interrupts这两个工具，它们能帮你快速判断问题到底出在驱动、设备树还是硬件。

7. 最后分享几个自己的实用习惯

7.1 开发阶段先确认环境，再动代码

我现在拿到一块新的IMX6ULL板卡做ADC，第一件事不是写驱动，而是先翻内核源码，确认当前内核有没有匹配的ADC驱动，设备树模板里有没有现成节点。如果有，直接改DTS把节点配好，启动后看sysfs能不能出数据。这个步骤能帮我快速判断硬件通路是否正常。硬件通路没验证之前就写驱动，出了问题很难分清是驱动问题还是硬件问题。

另外，我会在开发阶段专门留一个测试脚本，用循环读取的方式连续打印各通道原始值和换算电压，配合万用表或者信号发生器做交叉验证。一旦驱动有任何改动，跑一遍脚本看基线是否变化，比临时拼命令高效得多。

7.2 把换算公式和滤波逻辑沉淀到应用层

驱动里只返回原始值，电压换算和滤波全部放在应用层，这是我个人的习惯。原因很简单：如果驱动里把线性化曲线、滤波算法、校准偏移都写死，那换一块VREF不同的板卡，或者传感器类型变了，就得改内核代码重新编译，调试成本高。放到应用层，改完直接跑，还能快速对比不同滤波参数的效果。

同理，如果采集的是温度、压力这类物理量，建议把从电压到物理量的标定公式也放在应用层。这样驱动保持纯粹，应用层保留灵活性，等产品定型后再决定要不要把某些固定逻辑下沉到内核，都不迟。IMX6ULL上做ADC驱动开发，说到底不是跟寄存器较劲，而是跟Linux的框架、设备树和硬件特性打交道。把这套思路理顺了，后面再做其它外设驱动，你会发现很多东西都是相通的。