做嵌入式或者工业自动化的朋友十有八九都被问过这么一句话“都什么年代了还在用串口”问这话的人多半是被Wi-Fi、5G、千兆以太网“惯坏”的互联网工程师。但你真去车间、配电房、老旧产线、光伏电站转一圈就会发现RS232/RS485的线缆还在机柜里跑得欢甚至新交付的项目还在大量使用串口。串口不死不是情怀是硬道理。这篇文章我想把这背后的道理掰开揉碎讲清楚顺带把我这些年调串口踩过的坑、总结的方法论一次全倒出来。内容会覆盖从电平标准、UART帧格式、DMA接收、环形缓冲区到Linux/Windows下的设备排查、虚拟机透传再到PLC、HMI、嵌入式Linux设备的IIoT接入实战适合刚入门嵌入式想做工业数据采集的朋友也适合被串口折磨过的老鸟拿来查漏补缺。1. 为什么一条40岁的总线还在产线上“服役”1.1 先给串口做一个“全身体检”很多人把“串口”和“RS232”划等号这是第一个误区。串口在硬件层面其实分三层看最底层是电气标准RS232、RS485、TTL中间是协议层UART帧格式最上面才是各类应用协议Modbus RTU、自定义帧、AT指令。日常说的“串口”通常指UART这种异步串行通信方式它规定了数据怎么一比特一比特地发出去而RS232/RS485只是规定了这些比特在物理线缆上以什么电压、什么差分方式传输。历史节点也值得摆一下RS232标准诞生于1962年比很多人的爷爷年纪都大。RS485则是1983年才正式标准化算是个“中年人”。但标准老不代表技术落后恰恰相反这几十年的工业现场检验已经把串口这条技术路线打磨得极其皮实。1.2 工业现场离不开它的三个场景第一个场景是存量设备升级。工厂里大量服役超过十年的PLC、仪表、变频器、电表通信接口清一色是RS485或RS232。要做设备数据采集、做预测性维护绕不开这些物理口。你不能因为“串口老”就要求客户把全厂设备换一遍那预算足以让任何项目黄掉。第二个场景是短距低速控制类通信。很多传感器、执行器、扫码枪、称重仪表数据量就是几十个字节实时性要求也就几十毫秒。杀鸡用牛刀没必要上以太网。串口四根线一接几十块钱搞定稳定可靠。第三个场景是调试与维护通道。路由器、交换机、服务器、存储设备几乎都保留串口作为带外管理口。联想XCC、戴尔iDRAC这类管理接口虽然走IPMI网络但底层硬件调试口仍然保留串口。一线工程师包里常年备着USB转串口线这就是串口生命力的最好证明。2. 串口不死的底层逻辑2.1 物理层的“抗造体质”串口为什么在恶劣工业环境下还能稳定工作答案在物理层设计。RS485采用差分信号传输用A、B两线之间的电压差来表示逻辑0和1对共模干扰有天然的抑制能力。简单说外部电磁噪声会同时叠加在两根线上但它们的差值基本不变接收端只看差值干扰就被抵消了。这个原理和我们熟悉的CAN总线、USB高速差分是同一套思路只不过RS485把成本做到了最低。RS232虽然抗干扰不如RS485但它用的是±12V左右的摆幅信号相比TTL的3.3V或5V电平噪声容限大得多。在机柜内部短距离通信场景RS232的可靠性完全够用。反观这些年火起来的各种新总线动不动就要求屏蔽双绞线、严格接地、终端匹配稍不注意就出问题。串口在这方面反而“宽容”很多。另外一个容易被忽略的点是串口通信不依赖时钟线。UART靠双方约定波特率然后接收端在每位数据中间采样省掉一根时钟线就省掉了一个故障源。这就像两个人不用对表靠语速默契交流简单到极致自然难坏。2.2 协议层的“极简哲学”UART的帧格式简单到可以背下来一个起始位低电平5到8个数据位一个可选的校验位1到2个停止位高电平。发送空闲时线缆保持高电平起始位的下降沿就是接收端的“起跑枪声”。这种设计带来的直接好处是任何单片机、任何编程语言都能轻松实现或者直接调用现成外设。不需要协议栈不需要IP地址不需要握手协商。对于资源受限的MCU来说串口几乎是零负担占用的引脚少、内存少、CPU开销小。在动辄上万节点的工业网络中这种轻量级特性是宝贵的。2.3 存量设备形成的“护城河”技术淘汰从来不是看谁更新而是看存量生态有多大。目前全球在役的串口设备数量以亿计光是中国市场的工业仪表、PLC存量就是天文数字。这些设备背后是几十年的工艺积累、图纸资料、维护人员经验。更换通信方式的代价不仅是硬件成本还有产线停机损失、人员再培训成本这些都是真金白银。更现实的是IIoT工业物联网浪潮来了以后行业没有把串口干掉而是发明了一堆“中间人”设备串口服务器、DTU数据传输单元、边缘网关。它们把RS485/RS232转成以太网、Wi-Fi、4G让老设备的数据流向云平台。这不是串口的落幕而是串口的“二次上岗”——物理层还是那根线但数据通道焕然一新。3. 硬核拆解从电平到字节流3.1 UART帧格式逐位拆解以最常用的8N1格式为例8个数据位、无校验、1个停止位发送一个字节“0x55”在线缆上的波形是先是一个低电平起始位然后8个数据位从低位到高位依次输出0x55即01010101最后拉高一个比特时间的停止位。接收端在起始位下降沿后按波特率定时采样每位的中点避开信号跳变区域降低误码率。这里有个新手常犯的错误以为串口发送“0x55”就是线缆上出现8个高电平脉冲。实际上由于低位在前0x55的二进制是01010101发送顺序是1、0、1、0、1、0、1、0对应波形就是交替的高低电平。用示波器或者逻辑分析仪抓一次波形这个疑惑就永远解开了。3.2 TTL、RS232、RS485到底该选谁项目TTL电平RS232RS485电平标准0~3.3V/5V±3~±15V差分电压A-B传输距离1米以内15米左右1200米低速时通信方式单端单端差分可多机节点数1对11对1最大128或更多典型场景板级调试短距设备互联工业总线、仪表采集选型逻辑很简单板级调试、下载程序用TTL短距离一对一设备互联比如电脑连老式交换机管理口用RS232需要远距离、多设备挂总线无脑上RS485。需要注意的是USB转TTL模块输出的是TTL电平如果直接接到RS232设备上轻则通信失败重则烧毁接口芯片。买模块前一定看清设备端的电平标准。3.3 波特率的误差账本波特率是串口通信最容易出错又最难排查的环节。双方约定9600但实际时钟偏差超过一定范围采样点就会逐渐偏移到数据位边缘最终出现乱码。MCU侧常用外部晶振或者内部RC振荡器内部RC精度一般在±1%到±2%之间波特率越高允许的误差预算越紧。算一笔账9600波特率下每个比特时间约104.2微秒接收端在每位中点采样容许的累计偏差大约在半个比特时间以内换算下来误差容忍度接近±4%。到了115200波特率每个比特只有8.68微秒同样的采样策略误差容忍度也就降到±3%左右。如果MCU用了精度差的内部振荡器再加上USB转串口芯片那端的误差双向一叠加高温下就可能出乱码。实操建议涉及高波特率460800、921600时务必使用外部晶振或者精度在±0.5%以内的时钟源。USB转串口芯片尽量选FT232、CP2102、CH340这些成熟方案兼容性和时钟精度都有保障。遇到诡异乱码先用示波器量一下实际波形周期算算误差再怀疑程序。3.4 接线避坑指南串口接线看似简单坑却不少。RS232的Tx要接对端的RxRx接对端的TxGND必须共地很多人接错Tx/Rx导致收不到数据。RS485则是A接A、B接B尽量不要反虽然有些设备反了也能通因为很多设备有极性自适应但可靠性会打折扣。另一个高频问题是共地。TTL串口和USB转TTL模块之间如果不共地信号电平参考点不一致会出现偶发乱码或者完全不通。长距离RS485布线还要注意终端电阻总线两端各接一个120欧电阻防止信号反射。多机挂接时总线上每个节点的A/B线都要手拉手串联不能星型分叉否则反射会把波形搅得一团糟。屏蔽层接地也不能忽略。工业现场有大功率变频器、电机启动屏蔽层如果只在PLC侧单端接地抗干扰效果最理想。两端都接地反而可能形成地环路把干扰引进总线。4. 现代MCU如何“续命”串口4.1 GD32F470与STM32的USART外设差异这几年国产MCU大量替换ST芯片GD32系列是主角之一。以GD32F470VET6为例它的USART外设和STM32同宗同源寄存器布局和HAL库接口高度相似迁移成本很低。但细节上有差异GD32的USART时钟源配置、波特率寄存器计算方式和STM32略有不同尤其是使用HAL库时要注意时钟树配置是否正确否则会出现“程序跑了但波特率偏得离谱”的诡异现象。我实际用GD32F470做过多路串口采集一个比较深的体会是这类国产芯片的串口外设数量够用通常有6到8个UART但中断优先级和DMA通道分配需要仔细规划否则多路串口同时高频收发时中断嵌套会把CPU拖垮。硬件上没问题的前提是软件侧要有一套科学的接收架构这就引出下面的话题。4.2 DMA接收环形缓冲区这才是正确玩法串口接收如果只用中断逐字节处理在115200波特率下每秒进来11520字节意味着每87微秒就要进一次中断。如果主程序还要跑显示、刷传感器、处理通信协议分分钟被中断淹没。正确解法是DMA环形缓冲区ring buffer。核心思路分三层第一层UART外设收到数据后由DMA自动搬运到一块内存缓冲区完全不占CPU。第二层DMA传输完成或达到半满/全满阈值时触发一次中断把数据拷入环形缓冲区。第三层主循环或任务里从环形缓冲区按帧解析数据处理完就释放空间。这样CPU只在缓冲区翻转时忙一小会儿大部分时间都在干正事。环形缓冲区的实现有个关键细节读写指针要区分“读索引”和“写索引”判断满和空的条件不同。写满的判断是“写索引1等于读索引”读空的判断是“写索引等于读索引”。很多新手在这里踩坑缓冲区大小明明是256实际可用却是255就是因为少留了一个位置做满空判断。另外读写索引的变量类型要一致操作时要考虑原子性单核MCU上关中断或用临界区保护一下索引更新即可。用PlatformIO开发STM32时有人会遇到USE_USB_HOST_HS这类编译选项那是USB主机栈相关配置和普通串口无关别被报错误导。STM32F407VET6这类芯片的串口发送乱码多半不是DMA的问题而是时钟配置错了稍后在第7章细说。4.3 FPGA实现串口发送ASCII字符串MCU之外FPGA也常被要求实现串口。最典型的场景是FPGA需要向上位机打印状态信息比如把内部寄存器值、采集到的ADC结果以ASCII字符串形式发出来。很多人一上来就写复杂的UART状态机其实没必要。最简单可靠的方案是用计数器分频产生波特率时钟然后设计一个发送状态机空闲态等待触发发送态依次输出起始位、8位数据、停止位。发送ASCII字符串时核心是搞一个FIFO或者数组缓冲逐字节调用发送状态机每个字节发送完成后等待一个停止位时间再发下一字节。字符串建议用Hello UART\r\n这种以\r\n结尾的格式方便上位机按行解析。FPGA实现串口的优势是时序完全可控、没有中断延迟抖动适合对发送间隔有严格要求的场景。缺点是布线时序要小心尤其是跨时钟域处理时从系统时钟域到波特率时钟域的信号切换容易产生亚稳态需要用两级触发器同步。我第一次做的时候就是忘记同步结果逻辑分析仪上波形干干净净实际却偶发丢字节。4.4 USB转串口芯片怎么选PC端和MCU调试打交道的USB转串口芯片市面上主流四款CH340、CH341、CP2102、FT232。CH340/CH341国产主力价格便宜驱动兼容性不错Win7/Win10/Win11都有驱动缺点是高速模式下偶尔会丢数据。CP2102是Silicon Labs的经典款稳定性和兼容性均衡树莓派、Arduino生态大量在用。FT232算是“贵族”驱动成熟、抗造、支持能力强专业调试首选。选择逻辑看用途只是给Arduino下载程序、偶尔看个串口日志CH340够了做正式项目调试、长时间高波特率跑数据建议FT232或者CP2102。另外注意有些USB转TTL模块不带DTR/RTS控制脚引出会给自动下载电路带来麻烦买之前看清楚模块丝印。装完驱动之后设备管理器里不显示COM口别急着怪芯片先换根数据线试试——很多线只能充电不能传数据这个坑几乎人人都踩过。5. 操作系统侧的串口生存手册5.1 Linux下找到你的串口Linux下串口设备通常映射为/dev/ttyUSB0、/dev/ttyACM0、/dev/ttyS0等节点。查看可用串口的命令组合如下先ls /dev/tty*列出设备节点再用dmesg | grep tty或者dmesg | tail -n 20看内核识别日志能确认USB转串口芯片是否被正确枚举。如果是CH340/CH341内核自带ch341驱动CP2102对应cp210x驱动一般内核都编译进去了。如果设备节点有了但打不开八成是权限问题。可以把当前用户加入dialout组sudo usermod -aG dialout $USER然后重新登录。树莓派5这类开发板还需要注意系统默认把串口分配给了蓝牙或者控制台要用raspi-config关闭串口登录功能后才能用普通程序访问/dev/ttyAMA0或/dev/ttyS0。还有一个实用小技巧多块USB转串口同时插着设备节点会随机分配成ttyUSB0、ttyUSB1重启后可能换名。解决办法是写udev规则按芯片序列号或USB端口绑定固定别名。规则文件放在/etc/udev/rules.d/99-usb-serial.rules里用ATTRS{serial}或者KERNELS属性匹配别图省事只按idVendor分不然两块同型号芯片还是分不清。5.2 Windows下的串口占用排查Windows下查串口被谁占用老系统比如Win7没有现成的命令行工具需要借助系统API或者第三方工具。最直接的办法是用微软的Process Explorer在查找菜单里输入\Device\Serial相关句柄或者用串口调试助手先探测COM口是否被占用。常见坑是设备管理器里能看到COM3但打开报“端口被占用”。这通常是后台软件残留进程没退出比如之前崩溃的调试软件、虚拟串口工具残留、或者某种工业组态软件如MCGS、组态王开机自启把串口占了。解决办法打开任务管理器找到可疑进程逐一结束或者用命令行netstat -ano不行那是查网络的查串口要装Handle或Process Explorer。另外新插入USB转串口设备后COM口号一直被占可以在设备管理器里手动修改端口号或者删除“未知设备”后重新扫描。5.3 虚拟机串口透传配置VMware和VirtualBox都能把宿主机串口透传给虚拟机调试嵌入式Linux时非常有用。以VMware为例先在虚拟机设置里添加串行端口选择“使用物理串口”设备选物理COM口比如COM3然后启动虚拟机/dev/ttyS0或者/dev/ttyS1就能访问。VirtualBox的做法类似在设置-串口-启用串口端口模式选“主机设备”路径填/dev/ttyUSB0或COM3。透传配置里最常踩的坑是传输速率设置VMware里默认会问“I/O模式”选“轮询”还是“中断”直接影响稳定性。低波特率下轮询模式省CPU高波特率建议用中断模式。另外虚拟机里打开串口前确保宿主机上没有任何程序占用该COM口否则虚拟机会报“无法连接”。如果你是想调嵌入式Linux下的串口应用更推荐把文件系统里/etc/inittab的getty串口登录关掉否则一开机控制台就把串口占了程序永远打不开设备。5.4 虚拟串口软件的妙用虚拟串口工具如VSPD、Com0Com能在系统里凭空创建一对互连的虚拟COM口数据从COM5发出去就能从COM6收到。这玩意儿在开发阶段极其好用上位机软件还没接到真实硬件时可以用虚拟串口对做联调或者用两个虚拟串口把一个串口调试助手和一个自写脚本“背对背”接起来测试协议解析逻辑。实际项目中我还用虚拟串口做过串口网关的本地模拟把PLC侧的真实串口通过物理口接收程序内部读写逻辑全部指向虚拟串口对这样在没有PLC的办公环境里也能完整跑通整个采集流程。需要注意虚拟串口是软件模拟时序和真实硬件有差异涉及高速收发或者严格时序的场景最终一定要回归真实硬件验证。6. IIoT实战老设备如何“上云”6.1 Modbus RTU串口上最流行的工业协议IIoT采集底层数据串口上跑得最多的协议就是Modbus RTU。它是一种主从协议总线上有一个主站通常是PLC、网关或上位机多个从站仪表、电表、变频器通过功能码读写寄存器。帧格式很简单设备地址1字节 功能码1字节 数据N字节 CRC16校验2字节。主站发请求帧从站回响应帧一问一答没有并发冲突。实际做采集网关时最常见的问题是CRC校验算法写错。CRC16-Modbus的多项式是0xA001初始值是0xFFFF查表法效率高但表格数据一定从正规来源复制别手敲。另一个坑是主站轮询频率和从站响应时间不匹配有些老旧仪表响应要几十毫秒轮询太快会一直超时。轮询间隔建议从200毫秒起步逐步调小找到稳定临界点。Easy320这类国产PLC的串口通信编程通常在PLC的编程软件里配置通信口参数然后在梯形图里调用自由口通信指令。和Modbus RTU设备互联时建议PLC做主站、仪表做从站这样轮询逻辑简单调试也直观。如果要求PLC做从站让上位机来读注意地址映射表要提前规划好免得地址对不上导致上位机读到一堆无意义数据。6.2 串口服务器与DTU的选型把串口设备接入局域网上云主力设备是串口服务器走4G公网主力是DTU。选型先看接口数量单路还是多路再看电气标准是RS232还是RS485能不能复用最后看协议转换能力有些串口服务器内置Modbus网关功能可以直接把Modbus RTU转换成Modbus TCP省去上位机自己解析的麻烦。经验之谈民用级的串口服务器一两百块那种在办公环境用没问题但工业现场一定要选带隔离电源、宽温设计、导轨安装的型号。之前我在一个配电房项目里用过便宜的裸板串口服务器夏天温度一高就重启换成工业级之后两年没出过事。另外串口服务器的虚拟串口驱动把网络端口映射成Windows本地的COM口尽量不要在正式生产环境用稳定性不如直接走TCP Socket上位机用C#或Python写个TCP客户端接收数据更靠谱。6.3 嵌入式Linux设备接入串口树莓派、Jetson TK1、全志V3S这类跑Linux的板子接入串口设备核心是两件事设备树配置和应用程序编程。Jetson TK1这种老开发板默认串口可能没引出或者被控制台占用需要修改设备树使能UART节点。全志V3S板子更典型芯片内部集成了多个UART但很多核心板只引出UART0其他串口要自己飞线或者改板。Linux串口编程有几件必须做的事用termios结构体配置波特率、数据位、校验位、停止位设置原始模式cfmakeraw关闭回显和行缓冲设置VTIME和VMIN控制超时和最少读取字节数否则read会一直阻塞或者一次只返回一个字节。我见过太多人直接在Linux下用默认的“规范模式”读串口结果数据被换行符拆得七零八落还以为是设备发疯了。树莓派5的串口还有一个特殊点/dev/ttyAMA0通常被蓝牙占用/dev/ttyS0是mini UART频率跟随核心时钟CPU降频时波特率会漂。做串口通信最好用/dev/ttyAMA0并关闭蓝牙映射或者在设备树里重新配置引脚功能。新手最容易在这上面折腾一整天。6.4 上位机与HMI的串口通信上位机选型上C#的SerialPort类封装简单Unity做数字孪生或可视化项目时也用同一套API。C的话可以直接调ReadFile/WriteFile操作串口句柄或者用开源串口库。Python做快速原型用pyserial几乎零成本。MCGS这类组态软件自带串口驱动配置好设备地址和寄存器表就能和PLC通信但注意驱动版本和PLC型号的兼容性。一个很重要的经验上位机读取串口数据时永远不要相信“一包数据正好一次读完”。串口是流式协议应用层发的“一帧”在底层可能被拆成多段到达也可能多帧粘在一起。处理办法是定义一个字节缓冲区把每次收到的数据追加进去然后按照帧头、帧长、校验规则循环解析完整帧剩余数据保留到下一轮。Unity里做串口通信也同理DataReceived事件是异步线程回调不能直接操作Unity主线程的UI组件要使用线程安全队列或者主线程轮询。7. 串口调试踩坑实录7.1 工具链从串口助手到逻辑分析仪排查串口问题工具决定效率。最低配是串口调试助手支持十六进制收发、定时发送、保存日志是刚需。进阶是虚拟串口工具和串口监听器能旁路抓包。专业场景必须上逻辑分析仪逻辑分析仪可以同时抓TX、RX、还有设备端的电平信号一眼看出波形异常比盲调效率高十倍。我在调试STM32F407VET6串口发送乱码时就是用逻辑分析仪抓波形发现实际波特率快了一截查了半天是外部晶振配置成HSI内部时钟了。这种问题靠串口助手看数据根本定位不了只有波形能告诉你真相。信号质量判断还有一个土办法把TX和RX短接做回环测试如果自发自收能通说明MCU侧收发正常问题大概率在线缆或者对端设备。7.2 乱码问题的完整排查流程串口乱码是最经典的问题归纳起来五个方向波特率不一致、电平不匹配、接线错误、时钟偏差、干扰。我建议按顺序查先核对两端的波特率、数据位、校验位、停止位这些参数必须完全一致。再看电平标准TTL设备接RS232口必然乱码或不收。然后用回环测试排除接线问题。接着用逻辑分析仪测实际波特率和设定值对比。最后才是干扰工业现场的干扰通常在长线传输中表现明显表现为偶发乱码而不是持续乱码。还有一个隐藏原因电源不稳。USB转串口模块从USB取电5V如果电脑USB口供电不足或者接了延长线模块输出电压纹波大TTL信号质量差乱码就会神出鬼没。换一个供电质量好的USB口或者用带隔离的USB转串口模块往往立竿见影。7.3 数据丢失缓冲区、流控与系统调度Linux从串口接收数据丢失或者Windows上位机读串口偶尔少字节这个问题的根源几乎都在缓冲区。硬件FIFO溢出、驱动层缓冲区不够、应用层读取不及时三个环节哪一环堵住都丢数据。排查顺序先确认硬件流控RTS/CTS是不是需要开启如果对端设备开了流控而你没接那些脚数据就丢了。然后检查应用层接收循环是不是在DataReceived事件里做了耗时操作比如写数据库、打日志导致底层缓冲区被新数据淹没。最后把系统缓冲区调大Linux下用stty -F /dev/ttyUSB0 rxbuf 4096这类参数调Windows下用SetCommState设置InQueue大小。DMA接收时的数据丢失另有一个经典坑DMA的缓冲区大小必须能覆盖一帧最大可能的连贯数据否则半满中断时数据还在持续到达拷贝期间又来了新数据缓冲区就被覆盖了。解决办法是把DMA缓冲区开大两倍以上并尽快完成拷贝。单片机内存够的话给我按512字节起步设计别抠门。7.4 烧写失败不只是接线问题串口烧写失败是嵌入式入门第一道坎。CH340/CH341驱动装了但下载不进去先看BOOT引脚电平对不对STM32用串口ISP下载时BOOT0要拉高下载完再拉低复位运行。很多开发板BOOT0有拨码开关拨错位置是头号原因。排除BOOT后检查下载软件里的串口选择和波特率设置。STM32的ISP下载波特率一般建议先降到38400或57600别一上来就115200线材不好的话高速下载必失败。还有一种情况是下载到一半失败多半是DTR/RTS自动复位电路时序不对换一个支持自动下载的开发板或者手动复位软件点连接的同时按住复位键看到“连接中”再松开。西数硬盘的串口接法是维修圈的玩法在那个场景里串口是调试接口接法讲究电平是TTL别拿RS232电平直接怼上去。这个偏门用法就不展开了但道理相通接任何串口前先确认电平标准再确认引脚定义最后才上电。7.5 常用排查速查表现象优先排查项参考工具/方法完全收不到数据TX/RX接反、电平不匹配、共地缺失回环测试、万用表测电平持续乱码波特率不一致、晶振配置错误逻辑分析仪抓波形偶发乱码干扰、电源纹波、接线过长屏蔽线、隔离模块丢字节缓冲区溢出、流控未开、读取不及时DMA环形缓冲区烧写失败BOOT引脚、串口占用、波特率过高手动复位配合下载时序设备管理器无COM口驱动未装、数据线非数据线换线、重装驱动7.6 串口面试与封装思路串口话题也是嵌入式面试高频考点。面试官问“如何保证串口通信可靠性”不要只答“加校验”。正确的回答层次是物理层选RS485差分终端电阻屏蔽协议层加帧头帧尾、长度字段、CRC校验软件层用环形缓冲区DMA超时重传机制异常处理考虑断线重连、假数据过滤。这四层答全了基本能看出一个人对串口的理解深度。代码封装上串口驱动建议做成独立模块提供“打开、配置、发送、接收回调、关闭”五个标准接口底层是HAL库还是寄存器操作都不暴露给上层。接收部分用回调函数把完整帧抛给业务层业务层只关心解析不关心底层字节流怎么来的。这个模式我用了很多年换芯片平台时上层应用代码一行不用改只移植底层串口驱动即可。最后再分享一个我个人的实践体会串口这玩意儿的魅力在于它足够简单简单到你可以完全掌控它的每一个比特。我做IIoT项目这些年Wi-Fi断过、4G卡过、以太网被接错过但老老实实按规范走的RS485链路往往是最不需要操心的那一段。下次再有人问“串口怎么还不死”你可以笑着告诉他因为在一堆花里胡哨的协议里工程师最需要的是一个不会骗自己的老朋友。串口就是那个老朋友。
