ESP32-C3与ModbusRTU结合：六路ADC采集与RS485实战指南

上周有朋友问我能不能用一块二十几块的 ESP32-C3-Super-Mini把现场一台 ModbusRTU 仪表的寄存器读回来再顺便多采几路模拟量。这个需求在工业、农业、环境监测里太常见了我干脆从 RS485 收发控制一路调到 ADC 滤波把整套固件完整跑通顺手把代码整理成了下面这份可以直接编译的工程。文章会从硬件接线、ModbusRTU 主机原理、6 通道 ADC 采集细节讲到完整代码和排坑记录适合刚接触 ESP32-C3 或者做数据采集节点的小伙板照着抄。1. 项目需求解析与方案选型1.1 这个项目到底要解决什么问题很多现场采集场景都不是单一信号源。一台温湿度变送器通过 ModbusRTU 输出数字量旁边还有几路温度变送器、压力传感器或者光敏元件输出模拟电压这种情况如果上 PLC 成本偏高用树莓派又显得大材小用且实时性难保证。ESP32-C3-Super-Mini 这块小板子价格低、功耗小、体积跟拇指差不多自带 ADC 和 UART非常适合做小型的边缘采集汇聚节点。这个项目的核心需求拆开看只有两条一是作为 ModbusRTU 主机主动去读从站设备寄存器把设备数据拿回来二是同时完成 6 路模拟量采集把电压值换算成工程值。两条需求在时间线上是并行的所以固件里必须有一个合理的轮询周期既不能让 Modbus 主站请求卡死也不能让 ADC 采样阻塞太久这是整套代码设计的出发点。1.2 为什么选择 ESP32-C3-Super-Mini 而不是其他板子选 ESP32-C3-Super-Mini 原因很直接便宜、够用、生态熟。它用的是单核 RISC-V 架构主频最高 160MHz跑 Modbus 轮询加 ADC 采样绰绰有余。板子自带的 USB 转串口电路省掉了额外下载器插上 Type-C 线就能烧录和打印日志开发体验比裸芯片好太多。对比原版 ESP32 开发板C3-Super-Mini 在引脚数量上确实紧凑但反而逼你把资源规划做清楚。C3 内部有两个独立的 ADC 外设ADC1 有 5 个通道ADC2 有 5 个通道合起来理论上能采 10 路模拟量但如果程序开了 WiFiADC2 会直接失效这是 ESP32 系列的通病。所以在规划 6 通道采集时我用的是 ADC1 的 5 个通道加 ADC2 的 1 个通道前提是固件里不初始化 WiFi。如果你的应用必须开 WiFi那第六路就要靠外部模拟开关扩展这部分我在后面单独讲。1.3 整体架构与数据流设计整套系统的数据流可以从前往后画一条线ModbusRTU 从站设备通过 RS485 总线接到 MAX3485 收发器再进入 ESP32-C3 的 UART16 路模拟信号分别接在 GPIO0、GPIO1、GPIO2、GPIO3、GPIO4 和 GPIO5 上经过板载 ADC 转换成数字量主控在周期任务里先采样 ADC再发起 Modbus 读请求最后把两类数据合并成一行日志通过 USB CDC 输出到上位机。通信协议上RS485 是半双工总线ModbusRTU 是主从协议总线上同一时间只有一个主机在发起请求。ESP32-C3 作为主机需要控制 MAX3485 的发送使能引脚 DE发送请求时拉高接收响应时拉低。这个方向切换如果搞错最常见的结果就是发出去的命令自己又读回来了或者从站响应根本收不到后面排坑部分会重点讲。2. 硬件准备与接线细节2.1 元器件清单与选型建议做这个项目需要的东西并不多我这里列一份完整的清单ESP32-C3-Super-Mini 开发板 1 块MAX3485 或 SP3485 RS485 转 TTL 模块 1 个供电必须 3.3V支持 ModbusRTU 协议的从站设备 1 台调试时可以用 USB 转 485 模块接电脑代替6 路模拟信号源调试阶段直接用 6 个 10K 电位器接成电压源最方便杜邦线、面包板、120 欧姆终端电阻长距离调试用选元器件时最容易踩的坑就是 RS485 模块的供电电压。MAX3485 是 3.3V 供电的而很多便宜的 MAX485 模块是 5V 供电如果用 5V 模块接 ESP32-C3 的 3.3V UART 引脚逻辑电平不匹配轻则通信不稳定重则烧引脚。我的建议是直接选标称 3.3V 供电的 MAX3485 模块省心很多。2.2 引脚分配与 6 通道 ADC 对应关系ESP32-C3-Super-Mini 虽然引脚少但把资源分配清楚之后完全够用。我这里采用的引脚分配方案如下功能引脚说明ADC 通道 1GPIO0ADC1_CH0模拟输入ADC 通道 2GPIO1ADC1_CH1模拟输入ADC 通道 3GPIO2ADC1_CH2模拟输入ADC 通道 4GPIO3ADC1_CH3模拟输入ADC 通道 5GPIO4ADC1_CH4模拟输入ADC 通道 6GPIO5ADC2_CH0模拟输入WiFi 关闭时可用RS485 RXGPIO20UART1 RX接 MAX3485 的 RORS485 TXGPIO21UART1 TX接 MAX3485 的 DIRS485 DE/REGPIO10方向控制接 MAX3485 的 DE 和 REGPIO20 和 GPIO21 是 ESP32-C3 的 UART0 默认引脚但我在代码里用的是 Serial1在 ESP32 Arduino 内核中这三个 UART 的引脚都可以自由映射所以把 UART1 的 RX 和 TX 放到 GPIO20、GPIO21 上没有问题。GPIO10 作为普通 GPIO 输出专门用来控制 RS485 收发方向不参与模拟采集这样避免和 ADC 通道起冲突。2.3 RS485 收发切换与 MAX3485 接线RS485 是半双工差分通信挂在总线上的所有设备共享两根差分线 A 和 B。任何一个设备要往总线上发数据都要先把发送使能拉高发完之后要立刻拉低回到接收状态。MAX3485 这个芯片把接收使能 RE 和发送使能 DE 做成了两个引脚实际模块上通常把 RE 和 DE 连在一起由一个信号控制高电平发送低电平接收。接线时把 MAX3485 模块的 RXD 接 ESP32-C3 的 GPIO21TXD 接 GPIO20DE 接 GPIO10VCC 和 GND 分别接 3.3V 和 GND。模块的 A、B 端子接从站设备的 A、B 端子注意如果两个设备距离超过几十米需要在总线两端各并联一个 120 欧姆终端电阻短距离调试时可以不接但通信不稳定时优先检查这个电阻。还有一个容易被忽略的点RS485 总线要保证所有设备共地。如果从站设备是独立供电最好把从站设备的 GND 和 ESP32-C3 的 GND 接到一起否则总线电平可能会漂移导致通信时好时坏。3. ModbusRTU 主机核心原理解读3.1 主从通信流程与典型报文分析ModbusRTU 的本质很简单就是主机发请求从站回响应。以最常见的读保持寄存器功能码 0x03 为例主机发送的请求帧格式是从站地址、功能码、起始寄存器地址高字节、起始寄存器地址低字节、寄存器数量高字节、寄存器数量低字节、CRC16 低字节、CRC16 高字节。比如要读从站地址 1、起始寄存器地址 0x000A、连续 2 个寄存器请求帧就是01 03 00 0A 00 02 C5 CD从站正常响应时会返回自己的地址、功能码、字节数然后是寄存器数据最后是 CRC16。如果从站返回异常功能码最高位置 1返回异常码。调试时最好先用电脑上的 Modbus Slave 工具模拟从站把帧结构看明白再接真实设备。3.2 CRC16 校验的计算与验证方法ModbusRTU 的 CRC16 校验是整个协议里最容易写错的地方它用的多项式是 0x8005实现时通常用查表法或逐位法。查表法速度快适合在单片机上做高频轮询逐位法代码更短适合理解原理。我这里提供一个最常用的逐位计算函数uint16_t modbusCRC16(const uint8_t* data, uint16_t len) { uint16_t crc 0xFFFF; for (uint16_t i 0; i len; i) { crc ^ data[i]; for (uint8_t j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }校验结果 CRC16 在帧内的发送顺序是低字节在前、高字节在后也就是上面报文示例里的 C5 CD其中 CD 是 CRC16 的低字节C5 是高字节。调试时如果发现从站始终不响应第一步就是核对 CRC 对不对我建议在代码里把每一帧请求的 CRC 都打印出来和 Modbus 调试工具的报文对比。3.3 为什么必须处理 DE/RE 方向切换RS485 半双工的特性决定了同一时刻只能有一个方向的数据流向。如果 DE/RE 信号一直保持低电平芯片始终处于接收状态那么 ESP32-C3 往 UART 发送请求帧时TXD 引脚上的数据虽然能通过芯片的 DI 进到 A/B 总线但芯片的输出通道没有打开信号上不了总线如果一直保持高电平芯片一直在发送状态从站返回的响应又进不了接收通道。很多库和代码在初始化时把 DE/RE 固定拉高或拉低看似方便实际会让通信彻底失效。正确做法是在发送请求帧之前拉高 DE发送完成之后延迟几个字节的时间再拉低 DE重新进入接收状态。这个延迟不能太短否则 UART 发送移位寄存器还没把最后一个字节完全推出去方向就切回接收了轻则丢最后一个字节重则 CRC 不对。我用的是 emelianov 的 Modbus 库库的 begin 函数直接支持传入 DE 引脚库内部会在每次发送时自动完成方向切换省掉了手动控制的麻烦。如果你决定自己手写 Modbus 主机协议栈这个方向切换逻辑必须要自己处理。4. 6 通道 ADC 采集的实现细节4.1 ESP32-C3 的 ADC 资源与通道分配ESP32-C3 芯片内置两个 ADC 外设分别叫 ADC1 和 ADC2。ADC1 有 5 个通道映射到 GPIO0、GPIO1、GPIO2、GPIO3、GPIO4ADC2 也有 5 个通道映射到 GPIO5、GPIO6、GPIO7、GPIO8、GPIO9。理论上 10 个通道都能用但在 ESP32 系列芯片上只要 WiFi 功能被启用ADC2 就会被射频模块占用所有 ADC2 通道的数据都会变成无效值这是硬件设计上就决定了的。我做 6 通道采集用的方案很简单GPIO0 到 GPIO4 走 ADC1 的 5 个通道GPIO5 走 ADC2 的第 0 通道。前提很明确固件里不调用 WiFi 相关函数。如果你的项目必须在采集模拟量的同时保留 WiFi 功能那第六路就不能用 GPIO5 了需要外接一片 CD74HC4067 模拟开关把其中一个 ADC1 通道扩展成 8 路甚至 16 路通过三个 GPIO 选通地址切换通道代码里加一个通道切换函数即可。4.2 参考电压、衰减与量程设置ESP32-C3 的 ADC 内部参考电压并不是简单等于 3.3V实际有效测量范围与所选衰减档位直接相关。芯片支持 0dB 和 11dB 两种输入衰减0dB 时有效量程大约在 0 到 1.1V 左右11dB 时可以测量到 0 到 3.1V 左右由于不同芯片存在个体的参考电压差异需要通过 eFuse 中烧录的校准值来做修正。Arduino 环境下的 analogReadMilliVolts 函数会自动读取 eFuse 校准值返回单位是毫伏比直接读 ADC 原始值换算要准确得多。在使用之前我建议对每个 ADC 通道都显式设置衰减档位analogSetPinAttenuation(pin, ADC_11db);这样代码的可移植性更好不会因为不同开发板默认衰减档位不同导致读数差异。需要注意的是即使设置了 11dB 衰减输入电压也不要超过 3.3V超过量程会损坏引脚外部输入电压较高时先做分压处理。4.3 采样滤波与多通道轮询策略ADC 采集最怕的就是数据跳变尤其是接电位器、传感器这类模拟源时工频干扰、电源纹波、引脚悬空都会让数值来回跳。最简单有效的办法是滑动平均滤波我对每个通道连续采样 10 次取平均值每次采样间隔 100 微秒整个 6 通道一轮下来耗时大约 6 毫秒这种情况下完全不会被 Modbus 轮询周期拖累。采样时序上有一个小细节为了避免固定采样间隔和工频干扰形成混叠我在每次采样之间故意加了一个不固定的微秒级延迟虽然看起来不起眼但实测能明显改善数值毛刺。对精度要求更高的场景可以在算法上增加剔除最大值最小值的逻辑先去掉一个最高值和一个最低值再取平均能有效滤掉偶发的尖峰噪声。还有一个必须强调的坑STM32 和 ESP32 的 ADC 引脚默认可能是高阻输入悬空状态下读数会随机漂移。如果某个通道暂时没接传感器不要把它当成正常采样结果去看要在代码里预留标志位区分通道是否启用否则会把悬空值混进平均值里。5. 完整代码实现与逐段解析5.1 工程配置与依赖库准备这个工程的开发环境我推荐用 PlatformIO新建项目时选择开发板 esp32-c3-devkitm-1框架选 Arduino。如果用 Arduino IDE需要在开发板管理器里安装 esp32 by Espressif Systems 的支持包然后在库管理器里搜索并安装 ModbusRTU也就是 emelianov 写的 ModbusRTU 库。这个库虽然是 esp8266 时代出来的但支持 ESP32 系列API 非常简洁。库安装好之后编译之前先确认一下代码里的两个硬件串口有没有冲突。我在代码中使用 Serial 走 USB CDC 打印日志使用 Serial1 绑定 GPIO20 和 GPIO21 走 Modbus这样两路数据互不干扰开发调试时串口监视器里能干净地看到日志输出。5.2 完整可编译示例代码下面这段代码是基于我实际跑通的工程精简出来的可以直接复制到你的工程里使用。它的逻辑是每 1 秒完成一轮数据采集先同步采 6 路 ADC再发起 Modbus 读请求请求结果通过回调函数通知主循环打印成功或失败状态。#include ModbusRTU.h #define RS485_RX_PIN 20 #define RS485_TX_PIN 21 #define RS485_DE_PIN 10 #define MB_SLAVE_ID 1 #define MB_REG_START 0x000A #define MB_REG_COUNT 2 const uint8_t adcPins[6] {0, 1, 2, 3, 4, 5}; const char* adcNames[6] {CH0, CH1, CH2, CH3, CH4, CH5}; ModbusRTU mb; uint16_t mbData[MB_REG_COUNT]; float adcMv[6]; volatile bool mbDone false; volatile bool mbOk false; bool readDone(Modbus::ResultCode event, uint16_t transactionId, void* data) { mbDone true; mbOk (event Modbus::EX_SUCCESS); return true; } void readAllADC() { for (int i 0; i 6; i) { uint32_t sum 0; for (int j 0; j 10; j) { sum analogReadMilliVolts(adcPins[i]); delayMicroseconds(100); } adcMv[i] sum / 10.0f; } } void printResult() { Serial.printf(Modbus reg[%02X]: , MB_REG_START); for (int i 0; i MB_REG_COUNT; i) { Serial.printf(%04X , mbData[i]); } Serial.println(); for (int i 0; i 6; i) { Serial.printf(%s: %.1f mV\n, adcNames[i], adcMv[i]); } } void setup() { Serial.begin(115200); Serial1.begin(9600, SERIAL_8N1, RS485_RX_PIN, RS485_TX_PIN); for (int i 0; i 6; i) { analogSetPinAttenuation(adcPins[i], ADC_11db); } mb.begin(Serial1, RS485_DE_PIN); mb.setTimeout(100); mb.slave(0); } void loop() { mb.task(); static uint32_t lastTick 0; static bool waitingResp false; if (!waitingResp millis() - lastTick 1000) { readAllADC(); mbDone false; mbOk false; waitingResp true; if (!mb.readHreg(MB_SLAVE_ID, MB_REG_START, mbData, MB_REG_COUNT, readDone)) { waitingResp false; lastTick millis(); Serial.println(request failed); } } if (waitingResp mbDone) { waitingResp false; lastTick millis(); if (mbOk) { printResult(); } else { Serial.println(Modbus read timeout or error); } } }5.3 关键函数与代码逻辑说明代码里最重要的入口是 mb.readHreg 函数它把一次 Modbus 读请求交给库去处理函数调用之后不会同步等待从站返回而是立即返回 true真正的通信过程由 loop 里的 mb.task 驱动。这种异步设计的好处是不会阻塞主循环缺点是你必须每轮循环都调用 mb.task否则请求永远发不出去。readAllADC 函数在每个采集周期开始时同步执行6 个通道每个采 10 次加起来大概耗时 6 到 7 毫秒对 1 秒的轮询周期来说可以忽略。采样值直接以毫伏为单位存进全局数组 adcMv打印格式化时用 %.1f 保留一位小数这样在串口监视器里看起来非常直观。回调函数 readDone 只做两件事置完成标志和置成功标志。注意回调函数运行在库的内部任务上下文里不要在里面做延时、打印、或者修改复杂数据结构否则可能影响 Modbus 的收发时序。这也是我把串口打印放在主循环里的原因。6. 常见问题排查与调试实录6.1 几个高频问题与解决方案我在调这个项目的过程中踩了不少坑把最常见的几个问题和解决办法整理成了一张表后面再动手做的人可以参考现象可能原因排查方法Modbus 请求发出后从站没反应A/B 线接反对调 A/B 两条线再试从站有响应但主机收不到DE/RE 控制脚配置错误检查 GPIO10 是否输出到模块 DE 引脚通信偶发失败重启后恢复缺少终端电阻或共地问题加 120 欧终端电阻确认所有设备 GND 相连读取寄存器的值总是 0xFFFF起始地址或功能码不对用 Modbus Slave 工具确认寄存器地址ADC 数值跳变剧烈衰减档位设置不一致或通道悬空统一设置 ADC_11db悬空通道加标志位过滤使用 GPIO5 采到的值不对WiFi 被初始化导致 ADC2 失效确认代码没有调用 WiFi 相关函数6.2 调试 ModbusRTU 通信的实战技巧第一次调试 Modbus 通信时我强烈建议先用 USB 转 485 模块把电脑和从站设备连接在电脑上运行 Modbus Slave 工具手动发一帧读请求确认从站地址、寄存器地址和功能码都是正确的再让 ESP32-C3 上总线。这样可以把问题二分如果电脑能读到数据说明是 ESP32-C3 端的时序或引脚问题如果电脑也读不到那就是从站地址或者寄存器地址设置错了。借助逻辑分析仪是排查 RS485 时序问题的利器。把探头夹在 MAX3485 模块的 A 和 B 两线上抓一段通信波形能直接看到请求帧和响应帧的时间间隔也能看到 DE 信号是否正常翻转。没有逻辑分析仪的话可以把 MAX3485 模块上的 DI 引脚同时接到 ESP32-C3 的 GPIO10 上通过 GPIO10 高低电平变化粗略判断发送窗口是否正确。ADC 采集的调试相对简单我习惯在电路板上留几个测试点调试时用稳压电源输出一个固定电压接到不同 GPIO然后对比串口打印的毫伏值和万用表读数。如果两者偏差超过 20mV优先检查输入回路是否有分压电阻、滤波电容是否过大导致 ADC 采样时间不足或者采样次数太少噪声没有被平均掉。6.3 从单机调试到现场接线的经验总结当整个系统从桌面调试转入现场接线时有些在外面没暴露的问题会突然冒出来比如布线距离变长后雷击浪涌影响、大功率设备启停导致的电源跌落。这些东西在实验室环境不容易复现但现场一旦出问题排查成本非常高。我的经验是在成批量部署之前先做一次 7 天连续运行的老化测试同时用上位机记录每一轮 Modbus 通信的成功率和 ADC 数值的波动范围把异常数据积累下来再分析。5 到 8 米以内的短距离调试我通常不加终端电阻也能收到稳定数据但一旦距离超过 20 米或者总线上的设备数超过 5 个必须两端加 120 欧姆终端电阻否则会出现通讯抖动和偶发超时。总线上所有设备的地线也要尽量接成星形避免地环路带来共模干扰。这套工程我从裸板开始调到最后稳定运行大概只花了一个下午的时间。二十几块钱的板子、十几块钱的 MAX3485 模块就能完成原来需要 PLC 一部分功能才能做到的事情性价比还是很高的。如果你后续有类似的采集需求照着这篇文章的接线和代码走一遍大概率能少踩不少坑。最后再提醒一句第一次上电别急着接真实从站先用 USB 转 485 接电脑的 Modbus Slave 工具把通信调通再接现场设备排查起来会轻松很多。