Linux 驱动中如何实现 ADC 电流采样？

在 Linux 驱动里做 ADC 电流采样，最容易踩的坑不是“读不到 ADC 值”，而是读到了一个看似正常的 raw 值，却不知道它到底代表多少 mA，误差从哪里来，过流阈值该按硬件值还是软件值设置。

工程上要把这件事拆成三层：硬件把电流变成电压，ADC 把电压变成数字量，Linux 驱动再把数字量换算成可用的电流值。只要其中一层单位错了，后面的滤波、保护和上报都会跟着跑偏。

一、总览：ADC 电流采样不是只读一个通道

完整链路通常从电源或负载电流开始，经过采样电阻、运放或分压滤波，再进入 SoC ADC 通道。Linux 侧可能通过 IIO 子系统读取，也可能由 PMIC、SARADC 或外置 ADC 驱动提供 consumer channel。应用最终看到的是电流值，但驱动内部至少要经历 raw -> voltage -> current 这几步。

一个比较稳的设计习惯是先把所有参数写清楚：

• Rsense
  ：采样电阻阻值，建议统一成 mΩ 或 μΩ。
• Gain
  ：运放或电流检测芯片增益，注意是否包含反相或偏置。
• Vref
  ：ADC 参考电压，决定 raw 值和电压的换算比例。
• N bit
  ：ADC 分辨率，决定最小可分辨电压。
• Offset
  ：零电流时的偏移，很多项目的误差都藏在这里。

驱动实现时不要把这些值散落在代码里。更好的方式是从设备树、ACPI、平台数据或芯片寄存器读取，再在 probe 阶段做一次完整校验。否则硬件换一个采样电阻，软件却还按旧参数计算，问题会非常隐蔽。

二、硬件链路：先确认 ADC 看到的是什么电压

电流采样的硬件方案大体分两类：低边采样和高边采样。低边采样简单、成本低，但会抬高负载地；高边采样更符合电源完整性要求，但对共模范围、运放选型和布局噪声更敏感。

公式看起来很朴素：

●●●# 理想情况下的换算链路
Vshunt = Vadc / Gain
I      = Vshunt / Rsense

问题在于真实硬件很少这么理想。采样电阻有精度和温漂，运放有输入失调和带宽限制，ADC 有量化误差和参考电压误差，PCB 上还有开关电源纹波、地弹和走线耦合。驱动不能解决所有模拟问题，但驱动必须知道这些误差存在。

做板级 bring-up 时，我一般会先用万用表或示波器确认三个点：

• 采样电阻两端压降是否符合负载电流。
• ADC 输入脚电压是否落在允许范围内。
• ADC raw 值随负载变化是否单调、稳定、没有明显饱和。

如果 ADC 输入已经超量程，软件滤波只是在“美化错误”。如果零电流时 ADC 有固定偏移，驱动就需要做 offset 校准，否则小电流会一直显示不准。

三、IIO 驱动实现：Provider 负责采样，Consumer 负责业务换算

Linux 里推荐把 ADC 能力放到 IIO provider 驱动里，业务驱动通过 IIO consumer API 拿通道。这样 ADC 控制器、PMIC ADC、外置 ADC 都可以统一接入，上层电流检测驱动不需要关心底层寄存器细节。

设备树可以把 ADC 通道和硬件参数描述清楚：

●●●current_sense {
    compatible = "demo,adc-current-sense";
    io-channels = <&saradc 3>;        /* 使用 ADC3 作为采样输入 */
    io-channel-names = "sense";
    sense-resistor-milli-ohms = <10>; /* Rsense = 10 mΩ */
    amplifier-gain-milli = <50000>;   /* Gain = 50.000 倍 */
};

驱动里最关键的是把单位固定下来。下面示例假设 IIO provider 返回的是 ADC 输入端微伏值，实际项目要以对应 ADC 驱动的 ABI 为准：

●●●/* 读取 ADC 电压并换算成电流，单位统一用 uV、mΩ、mA */
staticint sample_current_ma(struct device *dev, struct iio_channel *chan,
int rsense_mohm, int gain_milli)
{
int adc_uv;
    s64 vshunt_uv;
int ret;

    ret = iio_read_channel_processed(chan, &adc_uv);
if (ret < 0)
return ret; /* 读取失败时不要上报旧电流 */

/* 运放输出还原到采样电阻两端电压 */
    vshunt_uv = div_s64((s64)adc_uv * 1000, gain_milli);

/* uV / mΩ = mA，这样可以避免浮点运算 */
return div_s64(vshunt_uv, rsense_mohm);
}

如果底层只能提供 raw 和 scale，也可以自己完成换算。重点不是 API 选哪一个，而是别让 raw、mV、uV、mA 在代码里混着飞。驱动代码里所有变量名最好带单位，例如 adc_uv、current_ma、rsense_mohm，这比注释更可靠。

四、滤波校准与调试：让数值可信，而不是看起来平滑

ADC 电流采样通常会有抖动，尤其是负载由 DC/DC、马达、背光或无线模块产生时。驱动层可以做去毛刺、滑动平均、限幅和阈值防抖，但要记住：滤波会带来响应延迟，保护类电流检测不能只追求曲线漂亮。

常见处理链路可以这样设计：

• 先丢弃明显异常的单点值，例如超出 ADC 量程或跳变过大的值。
• 再做固定窗口平均，窗口大小根据采样周期和响应时间确定。
• 零电流时记录 offset，换算前先扣除偏移。
• 用已知负载做增益校准，确认显示值和实测值误差。
• 过流判断增加 debounce，避免噪声触发误报。

调试时建议同时看内核日志、IIO sysfs 和外部仪表：

●●●# 查看 IIO 设备和通道，确认 ADC provider 是否注册成功
iio_info

# 读取原始 ADC 值和 scale，路径需要按实际 iio:device 编号调整
cat /sys/bus/iio/devices/iio:device0/in_voltage3_raw
cat /sys/bus/iio/devices/iio:device0/in_voltage3_scale

# 连续观察采样变化，配合负载切换或电子负载阶跃测试
watch -n 0.2'cat /sys/bus/iio/devices/iio:device0/in_voltage3_raw'

如果读数不准，排查顺序不要反过来。先看硬件量程和参考电压，再看 IIO 输出单位，然后看换算公式，最后才看滤波算法。很多“滤波不稳定”的问题，根因其实是采样点接错、增益参数错、ADC scale 理解错。

五、实战总结：把电流采样做成可交付能力

Linux 驱动里的 ADC 电流采样，真正的交付物不是一段 iio_read_channel_processed() 代码，而是一条可解释、可校准、可验证的测量链路。

落地时建议按这个顺序推进：

• 硬件确认：采样电阻、运放增益、ADC 量程、参考电压先闭环。
• 单位确认：所有变量、设备树属性和导出接口都写清单位。
• 误差确认：零点、满量程、温漂、噪声分别验证。
• 策略确认：滤波窗口、采样周期、过流阈值和响应时间一起评估。
• 接口确认：根据业务选择 power_supply、hwmon、IIO sysfs 或私有 debugfs。

一句话收尾：ADC 电流采样是模拟硬件和 Linux 驱动的交界面。硬件决定你能采到什么，IIO 决定你怎么拿到数据，驱动换算和滤波决定这个数值能不能被系统放心使用。