搞嵌入式开发的人一定遇到过这种场景手里一块单片机一堆串口设备结果客户说“数据要上以太网要让上位机远程读写”。要么花时间调协议栈要么上一颗以太网控制芯片自己写驱动哪个都不是省心事。我最早做这种需求时先是拿 STM32F407 配合 LAN8720 自己啃 RMII 接口和 lwIP后来发现项目工期一紧根本来不及折腾。那次之后我开始用 CH9120 这种透传芯片直接把串口和以太网之间的双向数据通道打通很多项目当天就能跑通演示。CH9120 是沁恒做的串口转以太网芯片芯片内部集成了 TCP/IP 协议栈和以太网 PHY外部只需要接一颗带网络变压器的 RJ45 座子就能把 UART 数据透明地搬到网络里也能把网络发来的数据原样交还串口。适合的场景很明确串口设备联网、工业仪表数据采集、扩展多个串口统一上网络。这篇文章我会把选型思路、接线、配置参数、实测过程和踩坑记录都拆开讲给后面要做类似方案的朋友一个可以直接照抄的参考。1. 为什么选 CH9120先搞清楚以太网方案的痛点1.1 串口设备联网的三种常见路线很多工程师一提到“单片机连以太网”第一个念头就是 MCU 自带 MAC 外接 PHY 跑协议栈。STM32F407 加一颗 LAN8720再移植 lwIP确实能做得很灵活但代价也很明显RMII 引脚分配、50MHz 时钟来源、复位时序、PHY 地址、DMA 描述符、内存池大小任何一个环节出问题都可能卡你好几天。尤其是第一次接触的人光是把网线插上去能 ping 通往往就要折腾一两天。第二条路线是 W5500 这类 SPI 接口的以太网控制芯片。W5500 把 TCP/IP 协议栈做进了芯片里MCU 只需要通过 SPI 读写寄存器稳定性比纯软件协议栈好很多。但它也有自己的问题SPI 通信有吞吐上限而且你还是要在 MCU 里写一段不小的驱动和 Socket 管理代码。如果需要同时处理多路 TCP 连接、心跳包、断线重连代码量一点不少。第三条路线就是 CH9120 这种“透明传输”芯片。它和我前面说的两种方案有本质区别它不需要 MCU 跑以太网协议栈也不需要 MCU 去管理 Socket甚至连 PHY 都集成在芯片里了。MCU 这边的串口发什么以太网那边就原样收到什么以太网那边发过来什么串口这边就原样输出什么。对 MCU 来说它只是在和一颗 UART 芯片通信而已。这种“把网络问题降维成串口问题”的思路在数据量不大、开发周期紧的项目里非常香。1.2 CH9120 能做什么、不能做什么CH9120 能做的事用一句话概括就是“串口字节流和以太网数据包之间的双向透明搬运”。它支持 TCP Server、TCP Client、UDP 等常用工作模式可以设置静态 IP也能自动获取 IP串口参数、分包方式、目标端口都可以配置。但有一点必须提前说清楚CH9120 不是协议解析芯片。它不会识别你发过来的是 Modbus RTU 还是 DL/T645-2007也不会帮你做 CRC 校验。它是“搬运工”不是“翻译官”。应用中常见的误区是有人以为把 CH9120 接在电表和上位机之间上位机就能直接读懂电表协议了。实际上CH9120 只是保证物理链路通应用层协议还是需要上位机或主控自己解析。那标题里说的“多串口协议”怎么理解我的理解是当一个系统里同时存在多种串口协议设备比如 PLC 用自定义协议、电表走 Modbus RTU、另一台仪表走 DL/T645单颗 CH9120 只能接一路串口但你可以用多颗 CH9120 分别接不同设备把它们各自的串口数据全部转换成以太网数据统一交给一个采集网关或上位机去处理。也就是说“多串口协议”是通过多路串口转以太网通道把不同协议的设备汇聚到同一个网络平面再用一层应用软件去做协议解析和数据整合。CH9120 解决的是“通道”问题不是“协议”问题。2. 硬件接线与最小系统搭建2.1 引脚功能与供电设计CH9120 的常用引脚不算多核心就是串口三根线加以太网差分对外加配置、复位和状态灯。我通常直接买带网络变压器和 RJ45 座的模块省去自己画差分电路和变压器的麻烦。引脚方向说明VCC电源3.3V 供电注意纹波GND电源所有设备必须共地RXD输入接 MCU/串口设备的 TXDTXD输出接 MCU/串口设备的 RXDRTS/CTS可选硬件流控普通场景可不接CFG输入配置模式使能通常拉低后上电进入配置模式RST输入复位低有效TXP/TXN以太网接 RJ45 变压器的差分发送对RXP/RXN以太网接 RJ45 变压器的差分接收对供电这块很多人会忽略。CH9120 是 3.3V 逻辑电平如果你的 MCU 是 5V 供电串口直接互连前最好确认 I/O 是否兼容。我习惯在 UART 线上加电阻分压或者用电平转换芯片虽然多数单片机引脚声称 5V 容忍但工业现场为了避免上电时序导致倒灌还是稳一点好。另外要特别注意CH9120 内置的是 MAC 和 PHY但网络变压器不在芯片内部。如果你买的是裸芯片必须外接带隔离变压器的 RJ45 座子不能把网线的 TX/RX 差分线直接焊到芯片引脚上。做模块的朋友一般已经处理好这部分买模块就省心很多。2.2 典型接线图文字版一个最简单的 CH9120 测试接线如下MCU/串口设备 CH9120 模块 TXD -------------- RXD RXD -------------- TXD GND --------------- GND以太网接口通过网线接到路由器或交换机PC 也接到同一台设备上。这样 MCU 串口发的数据会经过 CH9120 打包成网络包发给 PCPC 发给模块的数据则会从串口输出到 MCU。进入配置模式的方式不同模块可能略有区别但大部分是 CFG 引脚拉低后重新上电模块会进入配置状态此时不转发串口数据而是等待配置命令。有些模块上直接做了配置按键按下再上电就进配置。配置完成后拉高 CFG 或悬空重新上电进入透传模式。具体以你手上模块的数据手册为准我第一次用的时候就是因为没拔配置跳线结果串口数据怎么也发不到网络上去折腾了半天才发现模块一直停留在配置模式。3. 配置工具与关键参数3.1 两种配置方式CH9120 的配置方式主要有串口配置和网络配置两种。串口配置是把 UART 连接到 PC 的 USB 转串口工具进入配置模式后用串口指令读写配置项。这种方式适合产线批量烧写配置因为不需要 IP 通信只要串口线接好就能写。但缺点是命令格式不够直观要翻手册而且每条指令都要按寄存器地址来操作。网络配置是沁恒官方配置工具通过局域网搜索模块再在图形界面上填参数。这种方式最直观适合前期调试一个模块一个模块地设置。配置完成后模块需要重新上电才会按新参数运行。我在做原型验证时基本都用网络配置只有批量生产时才写脚本走串口配置。3.2 几个必须设置的参数配置界面里的参数不算多但每一项都影响实际使用。我按重要性排一下参数含义为什么重要本地 IP/掩码/网关模块在网络中的地址必须和上位机在同一网段否则数据路由失败工作模式TCP Server / TCP Client / UDP决定谁主动发起连接本地端口模块监听或绑定的端口上位机连接时要用这个端口目标 IP/目标端口数据要发给谁TCP Client 模式下必须先填对目标服务器串口波特率/数据位/校验位/停止位串口通信参数必须与所接串口设备一致分包超时/包长度阈值串口数据分组成包的策略直接影响粘包和拆包效果IP 配置这块最常见的坑是“能搜索到模块但连接不上”。很多模块出厂默认 IP 是 192.168.1.200 之类而你的电脑可能是 192.168.1.x 也可能不是。如果不在同一网段工具能搜到不代表数据能通必须先给电脑配一个同网段地址。另外如果现场网络里有 DHCP模块自动获取的 IP 可能会变上位机一旦把连接写死了就会断连。批量部署时建议用静态 IP并在系统里做好 IP 规划。3.3 工作模式的选型思路TCP Server 模式适合“模块被连接”的场景。比如上位机是主站它主动去连接设备侧的 CH9120模块上电后就在端口上等着。一般用在采集终端数量不多、上位机可以轮询所有设备的场合。这种模式下上位机可以随时断开再重连模块不需要关心远端状态。TCP Client 模式适合“模块主动找服务器”的场景。比如设备接入一个固定 IP 的物联网关CH9120 上电后主动发起 TCP 连接连接建立后数据双向跑。好处是网关只需要监听一个端口所有客户端都会自动连上来而且设备端不需要公网 IP。如果现场有防火墙或 NATTCP Client 比 TCP Server 好使很多。UDP 模式则不建立连接直接发包。延迟低、开销小但不可靠可能丢包、乱序。我一般不推荐在关键采集链路里用 UDP除非你的应用层协议自带重传和序号管理。CH9120 的定位是工业透传稳定性比“省一个 TCP 握手”更重要。还有一个“配对模式”简单理解就是两个 CH9120 之间建立直连通道把一边的串口数据传到另一边的串口。适合替代两根长串口线、或者两套设备之间做点对点透传。我做过一个项目两个控制柜距离一百多米直接拉 RS232 不现实就用两颗 CH9120 做了网线透传效果很稳定。3.4 组帧与分包最容易忽略的地方串口侧来的是一个连续字节流而以太网侧发的是一个个 IP 包。CH9120 怎么决定攒多少字节发一包这里就涉及“分包超时”和“包长度阈值”。分包超时是指“最后一个字节收到后等多久没新数据就把已缓存的数据发出去”。包长度阈值则是“缓存的数据达到多少字节立即发出”。这两个值配合决定了一个完整体串口帧会不会被拆散或者多个短帧会不会被黏成一包。以 Modbus RTU 为例协议规定相邻两个帧之间要有至少 3.5 个字符时间的空闲间隔。在 9600 波特率下一个字符约 1.04ms3.5 个字符约 3.64ms。如果你把分包超时设成 50ms且串口设备响应速度很快多个响应帧可能会在一个 50ms 窗口内到达结果全被黏成一个 TCP 包发给上位机。上位机如果按“收到一个包就算一帧”来解析就会出问题。更稳妥的做法是在应用层按协议帧格式解析而不是依赖 TCP 包边界。TCP 本身是字节流本来就不保证一包对应一帧。把 CH9120 的分包超时设成一个中间值比如 10ms让大多数一帧一包同时上位机里做一个小的缓冲区状态机按帧头和长度字段切帧。这样即使偶尔出现粘包也能正确还原。4. 双向转换实测从串口设备到上位机4.1 实验环境为了验证完整链路我搭了一套最简单的测试环境CH9120 模块、USB 转 TTL、PC 上的网络调试助手、PC 上的串口工具。接线方式就是前面说的模块 TTL 串口接 USB 转 TTL 的收发交叉模块网口接路由器PC 也接同一路由器。配置给模块设置成静态 IP 192.168.1.200本地端口 5000工作模式 TCP Server串口参数 9600 8N1分包超时设 10ms。配置完重新上电。PC 这边用网络调试助手创建一个 TCP Client连接 192.168.1.200:5000。连接成功后从串口工具往模块串口发一串十六进制数据PC 网络调试助手应当原样收到再从网络调试助手往模块发一串数据串口工具应当原样显示。这一步跑通说明最基本的存活链路没问题。4.2 TCP Server 模式下的双向数据流我习惯用 Modbus RTU 报文来做测试因为帧格式明确容易判断数据是否被破坏。比如往串口端发送01 03 00 00 00 02 C4 0B这是 Modbus RTU 读保持寄存器的请求前面是地址码和功能码最后两字节是 CRC。发送后网络调试助手收到的是完全一样的 8 个字节一个不多一个不少。反过来网络调试助手发送01 03 02 00 01 79 84串口工具同样能收到这 8 个字节。这就是“双向转换”最直观的体现CH9120 把串口侧的字节流封装成 TCP 数据包把 TCP 数据包还原成串口字节流没有增加或删减任何内容。有人会问它到底做了“转换”吗我觉得准确说它做的是“封装和还原”。物理层和链路层的介质变了但数据内容没有变因为应用层协议解析依然完全交给上位机或主控来做。这也是它能匹配“多串口协议”的原因——协议越杂越需要一个忠实的搬运工而不是一个半吊子的解析芯片。4.3 跑 Modbus 和 DL/T645 这类串口协议的注意点如果串口设备是 Modbus RTU 从机上位机作为主站轮询它那 CH9120 在链路上就是个完全透明的中间节点。只要串口参数一致Modbus 的地址、功能码、寄存器地址、CRC 都能原样通过。DL/T645-2007 电能表协议也类似。实际项目中我调过一台 DL/T645 电表波特率 2400偶校验数据帧由 0x68 起始0x16 结尾中间是地址域和控制码。CH9120 对这些完全无感帧进来什么样出去就是什么样。关键是上位机软件要按 DL/T645 的状态机去解析不要简单认为“一包就是一个完整帧”。因为 2400 波特率下一个字节约 4.17ms一帧如果是 20 多个字节串口电平上的持续时间就有 100ms 左右CH9120 的分包超时如果太小可能会把一个帧切成多个 TCP 包如果太大又可能把多个轮询响应黏在一起。所以最终还是那句老话应用层按协议格式解析不要依赖包边界。4.4 数据量和实时性实测简单的双向透传没有太多瓶颈。以 9600 波特率为例理论极限约 960 字节/秒以太网百兆接口的容量绰绰有余。就算把串口波特率拉到 115200也就 11.5KB/s 左右TCP 完全能扛住。我实测下来局域网内往返延迟基本在毫秒级主要延迟来自串口侧的字节发送时间而不是网络。比如 9600 波特率下发一帧 20 字节的数据光串口发送就要 20ms 左右网络侧再快整个链路的时间也主要由串口决定。所以想优化速度先提串口波特率再考虑网络参数。但要注意CH9120 不是为高吞吐设计的。它内部有缓冲但定位是透传模块不适合传几十 MB 的固件包或视频流。如果项目里需要大文件传输老老实实选 MCU 以太网协议栈自己控制或者走 TFTP/FTP 这种专门的传输通道。千万别说“既然网络是百兆就使劲发”串口侧到 CH9120 的数据输入速率是优先瓶颈。5. 常见问题与避坑指南5.1 配置后不生效、连不上这个问题出现的频率极高。我先列几个最常见的排查点模块供电正常吗看指示灯RJ45 座子上的 LINK/ACT 灯是否有反应。PC 和模块是否在同一网段先用 ping 测一下不通就不要再纠结工具配置。Windows 防火墙是否放行了调试端口很多时候工具能搜到但 TCP 连接失败是被防火墙拦了。配置写入后重新上电了吗很多模块配置是存入 Flash但运行参数还是旧的。工作模式是 TCP Client 吗如果是目标服务器没启动模块会一直连接失败这时候网络调试助手上看不到连接。CFG 引脚是否还在配置状态如果还停留在配置模式数据当然不会透传。我自己的习惯是拿到模块先恢复出厂设置再重新配置。因为二手的、别人调过的模块可能留着旧 IP 或旧串口参数不改干净就上电容易把问题引入到新项目里。5.2 数据乱码、丢字节、粘包乱码优先怀疑串口参数不一致。波特率、数据位、校验位、停止位只要有一个不匹配收到的数据就是花屏。另外就是 TTL 电平不一致或者信号线没共地。串口设备之间地电位差会导致误码率升高这种情况在工业现场尤其常见用隔离型 RS485 或增加隔离模块能解决。丢字节大多是因为上位机或 MCU 的串口接收缓冲处理不及时。如果主控串口中断里放了一堆耗时的操作UART 溢出标志置位后后面的数据就丢了。这里不是芯片问题是主控侧代码问题。排查时可以先用高波特率短帧测试如果短帧不丢、长帧丢基本就是接收缓冲溢出。粘包则是分包超时设得太长。比如串口设备连续返回两个帧中间间隔只有几毫秒而你设了 50ms 分包等待那么两帧就会被合并成一个 TCP 包发给上位机。解决办法是上位机按协议切帧因为无论你怎么设超时极端情况下都会存在粘包可能。5.3 和 ESP32LAN8720、STM32 以太网方案怎么选热词里经常看到 ESP32 连接 LAN8720 踩坑其实本质是“软件协议栈 外部 PHY”方案在硬件和驱动上引入了额外的复杂度。LAN8720 的 RMII 时钟必须由 MCU 提供 50MHz时钟引脚、PHY 地址、复位时序都容易出问题很多人还遇到过检测不到 PHY、收不到数据、只能 ping 通但 TCP 不通的怪现象。CH9120 把这些问题全封装掉了你只需要关心串口和 TCP 配置。维度CH9120 透传STM32 LAN8720 lwIPESP32 外挂 PHY开发量很低配置即可高驱动和协议栈都要调中等好在有现成例程灵活性低只能透传高可定制协议和数据流高还能跑 WiFi数据吞吐以串口速率为上限受限于 MCU 和协议栈但明显更宽高适用场景小数据量、快速交付大吞吐、复杂协议、需要定制处理混合网络场景项目选型时不要只看“哪个芯片更高级”。做采集控制类项目设备数据量通常很小一包几十字节每秒几次CH9120 完全够用而且不易出错。如果要做视频传输、文件传输、复杂的 TCP 服务器逻辑那再考虑 MCU 以太网方案。5.4 几个容易翻车的细节买模块时要确认它是否带了网络变压器和 RJ45 座。有的裸板只引出差分线需要自己接变压器。调试时用成品模块最省心但批量生产就要评估模块成本和体积。多片使用时记得给每一颗 CH9120 设置不同的 MAC 和 IP。如果都用默认设置交换机上可能出现 MAC 地址冲突表现为数据时通时不通。这个坑很隐蔽我第一次部署多通道网关时就遇到过当时查了半天网络最后才发现是 MAC 地址重复了。工业现场还要考虑雷击和浪涌。隔离型 RJ45 座子、TVS 管、合理的 PCB 布局都能降低损坏概率。透传芯片本身不便宜换一次模块的停工损失更大防护这块不要省。6. 从单路透传到多路串口协议汇聚6.1 多颗 CH9120 构建多串口采集网关前面说过单颗 CH9120 只能接一路串口。但项目里经常出现“一个采集柜里有多种型号的设备”的情况比如一路 PLC、一路 Modbus 电表、一路 DL/T645 电能表。应对办法有很多一种是每个串口设备各接一个 CH9120 模块直接独立入网另一种是用一颗带多路 UART 的 MCU把每路 UART 接到一颗 CH9120 上由 MCU 从网络侧读取或由上位机直接访问所有 IP。举一个实际设计例子通道设备串口协议/参数CH9120 IP本地端口工作模式通道1PLC自定义19200 8N1192.168.1.215001TCP Server通道2电表 AModbus RTU9600 8N1192.168.1.225002TCP Server通道3电表 BDL/T645-20072400 偶校验192.168.1.235003TCP Server上位机分别连接三个 IP 和端口相当于同时管理三个串口设备。这样做的好处是互不干扰某个设备出错不会影响其他通道坏处是占用多个网络连接和管理界面。如果设备数量多到几十路就要考虑用专门的串口服务器或集中式网关而不是无限堆 CH9120。6.2 应用层协议解析放哪里CH9120 把链路打通之后真正的协议解析和业务逻辑必须放在上游。对于“多串口协议”的最终整合我推荐把解析放在上位机或者边缘计算网关里因为 PC 或 Linux 网关处理 Modbus、DL/T645 的状态机非常容易资源也充足。嵌入式 MCU 如果性能不够只让它做透传和数据缓存就好不要硬塞太复杂的协议解析。如果你的需求是“主控通过以太网下发数据设备侧用串口协议去控制多个从机”那 CH9120 也只是承担主控和从机之间的数据通路真正的 Modbus 主站逻辑、DL/T645 协议栈还是要写在主控程序里。认清这一点使用 CH9120 时就不会把它当“万能协议转换盒”该写的代码不会少只是省去了网络协议栈的维护工作。6.3 工程化批量部署的心得批量部署和单台调试完全是两种场景。单台调试时IP 冲突了改一下就行串口参数错了重新配一次就完事。但几十台设备上线时逐台配参数会痛不欲生。所以我建议在项目初期就做好规划给每一颗 CH9120 用独立 MAC、独立 IP并建立台账记录现场位置。所有模块使用统一固件版本和配置模板启动前用脚本批量写入。网络环境里尽量使用静态 IP如果必须 DHCP就要在路由器上做 MAC-IP 绑定。配置参数导出备份现场设备异常时能快速恢复。上位机要有连接状态检测比如定期发送心跳查询发现 TCP 连接断开后主动重连。另外千万不要让系统“默认模块永远在线”。透传芯片、交换机、路由器都有可能出现瞬时故障应用层必须设计断线重连和告警机制。我在实际项目里见过有人把所有逻辑都建立在长期 TCP 连接上结果交换机重启一次所有采集通道全部静默直到人工发现。这种问题不是靠芯片能避免的必须从系统架构上解决。6.4 后续扩展方向CH9120 最常见的扩展方向是“串口设备上云”。你可以把多个 CH9120 的数据接入一个边缘网关网关里跑一个 Modbus TCP 或 MQTT 转换程序把底层串口协议统一成 JSON 或 MQTT 消息再上报到云端平台。这样做以后上层应用不再关心设备到底走 Modbus 还是 DL/T645只从统一接口取数即可。我还在类似项目里用过 Node-RED 做边缘规则引擎CH9120 的数据通过 TCP 进 Node-REDNode-RED 里写一个简单的 CRC 校验函数和帧解析状态机然后转成 MQTT 给物联网平台。整个原型只花了一个下午就搭起来了后面生产部署再换正式服务程序。对项目周期紧、又需要快速验证的场景这套组合非常实用。最后说一点个人体会。我用 CH9120 做过不少串口设备联网的项目最大的感觉是它不会帮你解决应用层问题但它能把最麻烦的链路层问题抹掉。项目上如果需求是几十个设备、低频率、小数据量、要快速交付CH9120 是很值得考虑的选择。反过来如果数据量很大、要求灵活的协议控制那就老老实实用 MCU 加协议栈。做技术选型前先想清楚你的瓶颈在哪比纠结芯片本身更重要。