把一台只有RS485串口的旧电表接进工厂局域网让上位机能远程抄数这个需求我今年已经碰到好几次了。头一回我打算换控制器结果现场设备完全不能动后来用了CH9120透传芯片在电表和网线之间加了一小块电路板问题当天就解决了。CH9120这类芯片解决的核心问题就是串口协议与以太网协议之间的双向转换MCU侧代码几乎不用改TCP/IP那摊子事全被芯片消化掉。如果你也在做串口设备联网、远程监控或者想把老设备接入物联网平台这篇实战记录应该能帮你少走几趟弯路。1. 为什么用CH9120给串口设备补一张以太网名片1.1 串口设备联网的老方案与新思路串口设备联网这件事行业内其实一直有几条路可以走只是每条路的代价不太一样。方案一MCU直接上以太网。比如STM32F407内置MAC外接LAN8720或DP83848这类PHY芯片自己在固件里跑lwIP协议栈。这个方案自由度最高但开发量也最大。RMII接口时序、PHY芯片复位顺序、MAC地址管理、协议栈裁剪每一项都能折腾好几天。我在一个数据采集项目里试过一次光调试网络驱动就花了接近一周最后发现是PHY芯片的时钟输入相位没对准。虽然最终跑通了但对一个只需要透传数据的项目来说性价比很低。方案二上工业串口服务器。MOXA、有人科技这类厂商的串口服务器产品很成熟RS485转以太网盒子接上就能用配置也简单。但价格摆在那里一个双串口的服务器几百块起步如果产品要量产这个成本压力很大。而且串口服务器体积不小很难塞进紧凑的设备外壳里。方案三用CH9120透传芯片集成到自己的板子上。CH9120是沁恒出的以太网透传芯片最大的特点是内部同时集成了以太网MAC、以太网PHY和完整的TCP/IP协议栈。外部MCU或者原本的串口设备根本不用理会网络协议只需要把数据通过UART丢给CH9120芯片自己完成打包、寻址、传输。我在改造旧设备时用到的正是这个方案。三条路放在一起对比优缺点非常明显方案开发量成本稳定性适用场景MCU外部PHY高中中对成本和体积敏感的批量产品工业串口服务器低高高现场改造、快速交付CH9120透传芯片低低高中小批量产品、嵌入式集成1.2 CH9120在整个方案中的角色定位用一句话概括CH9120的角色它是一个透明的数据管道把串口侧的比特流原封不动搬到网络侧再把网络侧收到的数据原封不动吐回串口。这个“透明”非常关键。对于原设备来说CH9120就像一个物理上变长的串口线对于上位机来说CH9120又像一个挂在网上的串口终端。它不关心串口数据里跑的是Modbus、DL/T645还是私有协议也正因为它不解析协议所以几乎可以适配任何串口通信场景。我习惯把它理解成“网线延长器在串口世界的镜像”网线延长器把电信号搬远CH9120把串口信号搬进TCP/IP世界。同时要注意CH9120本身是单串口芯片一颗芯片处理一路UART。如果需求是八路串口同时转以太网那就放八颗CH9120配合一个几块钱的交换机在逻辑上组成一个多串口服务器。这个点后面专门展开。2. 硬件设计关键点原理图、网口变压器与电平匹配2.1 最小系统供电、晶振、复位与串口脚CH9120硬件设计并不复杂但有几个地方不能马虎。供电方面芯片工作在3.3V但我建议在电源入口留一个稍大容量的滤波电容比如10uF并联0.1uF不要只放一个104。原因在于以太网PHY在收发数据时电流会产生瞬时波动如果电源滤波不足轻则丢包重则芯片直接复位。我踩过一次坑用LDO供电时输出端只放了一个100nF电容结果网口一跑大数据就偶尔掉线查到最后就是电源纹波问题。晶振方面CH9120需要一颗25MHz晶振旁边配两个负载电容容值按晶振规格书来通常18pF到22pF。这里有个小技巧晶振尽量靠近芯片时钟引脚走线短而直两个负载电容的地尽量单点接入芯片地。这不是玄学晶振区域处理不好以太网传输质量会直接劣化。复位电路建议用一个简单的RC复位即可比如10K电阻上拉到3.3V引脚接一个1uF电容到地。注意上电后要确保外部主控等CH9120复位完成再去配置它否则第一次配置可能写不进去。很多“配置失败”的问题本质是复位时序不对。串口引脚方面CH9120的TXD接外部MCU的RXDCH9120的RXD接外部MCU的TXD交叉连接。电平是3.3V如果外部MCU是5V供电务必做电平转换不能直接怼。用两颗MOS管搭双向电平转换是最便宜的方式也可以用TXS0108这类专用芯片工程上求稳的话上集成方案。2.2 以太网物理层网络变压器与RJ45的一体化接法CH9120内部已经集成了PHY所以外部不再需要单独的以太网PHY芯片这是它和“MCULAN8720”方案最大的区别。你只需要在CH9120的差分信号引脚上接一颗网络变压器再接RJ45座子以太网物理层就齐了。实际项目里我最推荐用的是带网络变压器的一体式RJ45座子最典型的就是HR911105A这类型号。它的好处非常直接内部把网络变压器、共模电感、RJ45焊接端子集成在一起PCB布局面积大幅缩小而且走线寄生参数由连接器本身保证省去自己调试变压器圈数比和中心抽头的麻烦。差分走线一定要记住几个原则TX±和RX±两对线各自等长差分阻抗控制在100欧姆左右走线尽量短远离晶振和时钟线不要在差分线下面铺大块地铜造成阻抗突变。如果你用两层板做参考平面一定要连续不要跨分割。用四层板当然更好。网络变压器中心抽头的处理请按照具体连接器型号的规格书来不同型号要求不同有的接3.3V有的接电源地有的直接悬空。千万不要所有型号都照搬同一个接法我见过一个团队因为中心抽头接反网线一插上芯片就发烫。另外建议大家把网口连接器的Link/ACT指示灯留出来。调试时这两颗灯能省下大量时间Link灯不亮说明物理层没建立插上网线后Link灯亮但Ping不通再往上层查配置。2.3 TTL/RS232/RS485多协议电平的扩展电路CH9120本身的串口引脚是TTL电平但这不代表它只能接TTL设备。配合不同的电平转换芯片就能覆盖最常见的三种串口物理层协议。TTL直接连接3.3V TTL设备可以直接对接无需额外电路。RS232外接MAX3232或SP3232注意RS232电平需要正负电压这些芯片内部有电荷泵外围只需几个0.1uF的电容。RS485外接SP3485或MAX3485A/B线之间加120欧姆终端电阻根据总线上设备数量决定是否加偏置电阻。需要注意RS485是半双工总线收发方向需要控制。CH9120不会自动帮你切换485收发器的方向常规做法是在硬件上做一个自动换向电路把CH9120的TXD信号经过反相后接到收发器的DE/RE控制脚。设计时要特别注意切换时序发送结束后必须留出足够的延迟等到最后一个字节完全发出后再释放总线否则会截断帧尾这是RS485透传乱码的一大来源。如果对自动换向电路心里没底也可以用外部MCU的一个GPIO来控制收发器的方向逻辑上更可控。这里就体现出“多串口协议”的扩展方式了CH9120解决的是协议栈问题和网络接入问题而RS232、RS485、TTL的电平差异由外部物理层芯片解决。两者搭配一套核心电路就能覆盖多种串口设备。3. 配置与模式选择把双向透传调到最优3.1 串口配置与网络配置两条路径CH9120支持两种配置方式一种是通过官方上位机工具在局域网内搜索设备修改参数一种是通过串口发送配置命令。两种方式各有适用场景。局域网配置工具适合开发调试阶段把芯片接入交换机电脑用工具搜索到设备然后图形化修改IP、端口、波特率等参数。整个过程类似配置一台小路由器对新手非常友好。注意电脑网卡和芯片要处在同一网段如果不知道芯片当前IP先把电脑IP设置成和芯片默认IP同网段。不确定默认IP是多少时最简单的办法是接个串口用串口配置方式读取当前参数。串口配置方式更适合量产阶段。CH9120在上电后有一段配置窗口时间此时通过UART发送特定格式的配置帧可以完成全部参数设置。具体帧格式请以芯片数据手册为准这里不展开。量产时我一般把配置命令封装在产测固件里板子贴片完成后用治具自动写入每一颗芯片的MAC地址和IP避免人工操作导致配置遗漏。不管用哪种方式配置完以后通常需要复位芯片或者重新上电让参数生效这一点在文档里不容易注意到产品说明书也不一定强调。我习惯在配置工具写入成功后延时1秒再对芯片做一次硬件复位确保配置可靠落盘。3.2 TCP Server、TCP Client、UDP模式的选用逻辑CH9120的三种工作模式本质上是让芯片站在不同的网络角色上。选择哪种模式取决于上位机软件和现场网络拓扑。TCP Server模式适合“上位机主动连接设备”的场景。芯片在指定本地端口上监听上位机作为客户端发起连接。我做的电表抄收项目就是这种模式Kepware所在的上位机通过网络主动连接CH9120连接建立后开始轮询电表。这种模式有个好处芯片只听不主动找安全性相对好也不容易把数据发错目标。TCP Client模式适合“设备主动上报”的场景。芯片上电后主动连接预先配置好的目标服务器IP和端口数据随时可以推上去。比如物联网采集终端把传感器数据定期上报到局域网里的数据服务器用Client模式是最自然的。要注意配置好掉线重连机制正常情况下芯片会自动重连但重连期间的数据可能会有部分滞留需要在协议层做好补偿。UDP模式则是最简单直接的网络收发方式无连接、开销小、延迟低但也最不可靠数据可能丢失、乱序、重复。它适合对实时性要求高但对完整性容忍度高的场景比如视频流、高速传感器数据工业控制尤其是Modbus轮询、电表抄收这类事务性通信我强烈建议用TCP而不是UDP。三种模式的选择没有一个绝对正确核心是看谁发起连接、谁是接收方、数据能否容忍丢失。下表是我在项目选型时的一个习惯场景推荐模式原因上位机主动轮询串口设备TCP Server连接由上位机发起芯片被动等待设备主动上报数据TCP Client芯片上电即连服务器大数据量实时视频/波形传输UDP低延迟牺牲部分可靠性工业控制/电表抄收TCP Server或Client可靠传输TCP重传机制兜底3.3 关于透传缓冲、分包和可靠性的配置思路透明传输听起来很“透明”但做起来有一个绕不开的话题分包。串口数据是一串连续字节流而TCP是一个流式协议芯片必须在某个时机把收到的串口数据组成一个TCP报文段发出去。如果每收到一个字节就发一个包网络开销巨大如果一直攒着不发又会产生延迟。CH9120内部处理这个问题的思路是采用缓冲加超时机制。数据到达串口后先进入芯片内部的缓冲区当缓冲区达到一定字节数或者持续一段时间没有新的数据就触发一次网络发送。这个机制你不需要深入掌握每个寄存器的细节但必须理解它的存在因为它直接影响上层协议的实时性。在实践中Modbus RTU这类协议对时序很敏感。RTU规定帧与帧之间需要保持至少3.5个字符时间的静默间隔而帧内部字节之间不能有超过1.5个字符时间的间隔。如果透传芯片的打包超时时间设置得不好一个完整的Modbus帧可能被拆成多个TCP包或者两个相邻帧被合并成一个TCP包发给上位机上位机解析时就会出错。针对这种情况我的经验是配置串口透传时尽量把芯片的打包超时设置为略小于设备帧间隔的值但不要小于帧内部字节间隔这样既不会把帧拆碎也不会把多帧粘连。具体数值要看串口波特率。9600波特率下3.5个字符的静默时间大概是4ms左右打包超时设在3ms到4ms就比较合理。如果上位机软件的解析能力足够强也可以不纠结这些直接按协议帧解析因为粘包拆包问题本质上是上位机要解决的。4. 双向转换的内部逻辑与性能边界4.1 内置TCP/IP协议栈做了什么很多做单片机开发的朋友第一次接触CH9120会问同一个问题它和直接用单片机跑协议栈到底差在哪区别就在于CH9120把网络协议栈“硬固化”在了芯片内部。你不需要初始化链路层、不需要处理ARP请求、不需要维护TCP状态机这些全由芯片内部逻辑完成。你看到的只是一个串口数据管道就像访问一个普通串口外设一样。这对MCU的资源占用是巨大的解放尤其适合那些还在用8位单片机、Flash和RAM都紧张的老设备。这里补充一点容易忽视的细节既然CH9120内置了PHY就意味着它的以太网差分引脚已经可以直接挂网络变压器但也意味着它没有RMII/MII接口不能再外接PHY扩展成其他速率等级。它就是一个标准的10/100M以太网接口不要把它当成一个MAC芯片去用。4.2 数据流向与节拍匹配双向转换的数据流向我用一个很直白的例子拆解。设备侧DMA从传感器读出一帧数据通过UART发给CH9120进入芯片的接收缓冲区。芯片按前面说的分包策略把数据拼成一个TCP段交给内部协议栈封装成IP报文交给内部PHY转换成差分信号经过网络变压器耦合到网线上最终到达上位机的Socket接收缓冲区。整个过程中外部MCU完全不参与TCP/IP处理。反向流程也一样上位机调用send()发出数据TCP报文经过网络抵达CH9120芯片剥离TCP/IP头把实际载荷通过UART发送给设备。如果设备是RS485接口数据还要经过外部的485收发器换向之后才能送到总线上。双向转换的节拍匹配是必须考虑的问题。串口侧的速率和网络侧的速度并不天然相等。比如串口波特率115200理论吞吐大约11.5KB/s而100M以太网的理论吞吐在12.5MB/s相差近千倍。如果上位机持续向设备下发大块数据而串口侧波特率很低芯片缓冲区迟早会被写满继续下发就会丢包。反过来如果串口设备瞬间吐出一大串数据而TCP对端没有及时读取芯片缓冲区也会溢出。所以控制好对端程序的读取节奏或者整体限制应用层的数据流量比单纯提高缓冲区更有效。4.3 多串口扩展架构与交换机级联回到标题里提到的“多串口协议”需求。CH9120是单串口芯片那么多串口怎么构建我的做法是“横向堆叠”一块主板上放多颗CH9120每颗配一个独立串口、独立IP、独立端口然后统一接到一颗交换芯片或者外接交换机对外呈现为一个多串口网关。这种分散式架构的优势在于故障隔离。某一个串口通道出错时只需要单独复位对应那颗CH9120不影响其他通道。集中式串口服务器虽然管理统一但一台设备崩了所有串口都瘫痪。工业现场考虑到可靠性我通常偏向分散式设计。软件层面多路CH9120可以通过虚拟串口软件映射成多个COM口原有基于串口的上位机软件几乎不用改。这也是很多传统行业改造的刚需软件是用VB6.0写的串口程序不敢乱动那就让CH9120在底层把网络变成串口软件层面完全感知不到变化。5. 实战问题排查从LAN8720到STM32F407的共性教训5.1 网络不通时的排查顺序我一向认为以太网芯片调不通十有八九不是芯片坏而是外围没处理好。这个论断在CH9120和之前调试ESP32LAN8720模块时都反复得到验证。很多网上教程说ESP32连LAN8720常遇到三个问题模块没复位、sleep mode导致PHY锁死、引脚虚焊。这些坑在CH9120上换了一层皮继续出现。遇到网络不通我固定按以下顺序排查看网口Link灯。插上网线Link灯不亮说明物理层就没通可能网线、变压器、差分走线有问题。优先换一根网线排除网线本身故障。量晶振。用示波器量CH9120的25MHz晶振引脚确认有正常振荡波形。示波器没有就直接换上备用晶振试。晶振不起振是PHY类芯片最常见的故障LAN8720如此CH9120也不例外。查复位。确认复位引脚在上电后稳定在高电平或低电平按手册要求没有周期性抖动。Ping芯片IP。物理层没问题就配置静态IP电脑和芯片接入同一个交换机Ping目标IP。Ping不通再查配置工具能否搜到芯片搜不到则怀疑芯片工作状态异常重新烧写配置。抓包确认。在电脑上用Wireshark抓取ARP和ICMP报文确认芯片是否有响应。这一步能快速区分问题是出在物理层、链路层还是配置层。这套排查链路跑完90%的“网口不通”都能定位。我在帮朋友调试ESP32LAN8720时发现模块的复位引脚被他接到了某个PWM输出脚上导致PHY一直在复位网络永远起不来。这个问题的本质和CH9120复位时序不对一模一样都是外围主控没有给PHY一个干净的工作起点。5.2 乱码与丢包大部分是电平、波特率和地线问题透传出现乱码不要先怀疑芯片。数据显示乱码十个里有八个是物理层配置问题。第一个坑是波特率不匹配。CH9120配置的波特率和外部设备/主控的实际波特率不一致最常见的现象就是偶尔能收到一两个正确字符大部分时间乱码。尤其是使用非标准波特率时比如4800、19200这种有些主流的USART外设算出来的实际波特率存在微小偏差长时间大量传输后误差累积就会出现错位。遇到这种情况用逻辑分析仪实测一下TXD引脚的实际波特率以实测值为准配置CH9120。第二个坑是TTL电平不共地。CH9120和外部设备是两套独立供电系统时如果只接TX、RX两根信号线不接地线参考电平不一致数据必然出错。两个系统之间一定有一条共同的GND连接。第三个坑是RS485方向切换。485总线是半双工CH9120的数据沿TXD发送后如果485收发器没有及时释放总线回波数据会干扰到自己的接收通道造成环回乱码。我建议在硬件上加自动换向电路后用示波器看A/B差分波形确认波形完整、没有毛刺和台阶。丢包问题则要多角度排查。对端TCP程序没有及时调用read()Windows调试助手缓存撑满网线质量差这些都可能造成丢包。有一种丢包现象很隐蔽上位机用小包高频发送网络侧正常但CH9120转发到串口时由于串口速率较慢缓冲区溢出后直接丢弃。定位到这类问题后要么降低串口波特率以上速率匹配要么在协议层做流控。CH9120透传模式下没有硬件流控脚这一点和带RTS/CTS的串口设备不同应用上要提前考虑到。5.3 和STM32F407等主控联调的三个坑在CH9120的嵌入式集成项目里主控最常见的是STM32F407这类带丰富外设的MCU。实际联调过程中我遇到过三个很有代表性的坑写在这里供参考。第一个坑是串口引脚复用冲突。F407的USART数量多但引脚复用关系复杂比如某个UART的TX/RX和片上其他外设冲突导致初始化时外设之间互相干扰。解决方法是选型阶段就把引脚表拉出来核对形成项目外设占用表而不是让出错的字符来决定引脚分配。第二个坑是DMA加空闲中断配合透传。F407跑串口透传时如果接收端用DMA搬运数据建议用串口空闲中断来触发一帧数据接收完成再配合DMA的循环模式。CH9120发送过来的数据是连续流如果只用逐字节中断高波特率下MCU容易被中断风暴淹没。这个坑不算CH9120本身的问题但在F407联调时几乎必踩。第三个坑是电平匹配。CH9120的IO是3.3VF407大部分IO也是3.3V这点没问题。但如果F407板子上某些区域是5V容忍引脚焊接或者复用时接错轻则电平不匹配乱码重则损坏引脚。联调之前务必确认串口引脚在数据手册上的标注。6. 场景化进阶电表抄收、Kepware接入与车载台架6.1 用CH9120把DL/T645-2007电表变成以太网从站项目里最典型的需求就是电能表接入网络。DL/T645-2007是电能表通信的老标准物理层通常是RS485波特率常见9600数据格式8E18数据位、偶校验、1停止位一帧数据包含帧头、长度、控制码、数据和校验和。改造思路非常直接电表RS485接CH9120外围的485收发器CH9120接入局域网上位机软件通过网络连接CH9120的TCP端口发送DL/T645帧协议帧原封不动透过网络到达电表电表返回的数据再透传回上位机。这里的核心不是硬件而是保证帧时序。DL/T645和Modbus RTU一样都有帧内字节间隔和帧间间隔的约束。CH9120的透传打包策略如果设置得太激进可能导致一个完整帧被拆成多个TCP包到达上位机上位机接收时如果不做跨包重组就会报帧解析错误。我实际的解决办法是上位机接收线程设置一个短暂超时比如20ms到50ms超时未再接收到数据就把之前收到的数据当作一个完整帧来处理同时把CH9120的打包超时设置在2ms到3ms让TCP包切割点尽量落在电表485总线的静默期。6.2 从Modbus RTU到Modbus TCP工业软件怎么接很多人在这一步会有一个误解以为CH9120实现了“Modbus RTU转Modbus TCP协议转换”。其实不是。CH9120只负责透明传输它不解析Modbus也不修改报文内容。它做的事情是让Modbus RTU的串口数据流跨越以太网而不是把Modbus RTU协议翻译成Modbus TCP协议。如果现场设备只支持Modbus RTU而上位机软件只支持Modbus TCP那么中间必须有一个协议转换层。这个转换层通常有两种实现方式方式一在上位机内部用虚拟串口软件把远程CH9120映射成一个本地COM口然后继续使用Modbus RTU主站驱动。Kepware配置一个Modbus Serial驱动指定到虚拟COM口就能正常轮询下位机。这种方式不改动协议只是把网络链路虚拟成串口链路非常稳。方式二使用专门的Modbus网关设备或者有协议转换功能的串口服务器由网关把上位机发来的Modbus TCP报文解包并去掉MBAP头再按Modbus RTU重新封装加上CRC发给串口设备。CH9120本身不带这个功能如果需要这种方案要选支持Modbus协议转换的网关产品不能拿CH9120硬顶。我在Kepware项目里的实际经验是能用虚拟串口解决的就不要让CH9120去承担协议转换的职责。协议转换应该在它最擅长的位置去做而不是在一个透明管道里勉强施加业务逻辑。6.3 在车载以太网测试台架中的正确用法这几年车载以太网很热车载以太网用的是100BASE-T1物理层是单对差分线和普通以太网的双对线完全不同。CH9120是普通以太网PHY不是100BASE-T1 PHY所以它不能直接接入车载以太网总线也别指望用它做车载以太网节点。但在车载台架测试里CH9120依然有自己的位置。比如一块域控制器样件它的调试串口需要把Log信息送到测试电脑的自动化脚本里而测试电脑在另一个房间串口线拉不过去。这时候就可以在样件旁边放一块CH9120转接板把调试串口转成标准以太网通过交换机和测试电脑通信。测试电脑上开一个TCP端口接收LogWireshark也能抓既解决了距离问题又保留了调试数据的完整性。而真正走车载以太网总线的报文监控应该用专业的100BASE-T1转接设备或者车载以太网网关这个设备选型要严格区分不要混用。最后分享几个实操经验CH9120我做过的项目前后有七八个从电表抄收到串口Log采集都试过最大的体会是把它当成一个纯粹可靠的管道不要给它赋予太多业务功能是最不容易出错的使用方式。协议解析放在上位机或者MCU里芯片只管透明转发分工越清晰系统越稳定。具体还有几个小建议硬件上花一个小时认真处理网络变压器和晶振后面能省三天调网络的时间多路串口需求提前在PCB上预留好复位按键和测试点量产和售后会方便很多配置参数写完后最好断电重新上电试一次确认配置真的固化进了芯片避免现场交付后出现“配置丢失”的假象。官方数据手册里关于寄存器配置和默认参数的内容我建议打印一份放在工位上网络问题排查时随手翻一翻比上网现查快得多。