1. 9针串口调试到底在调什么从物理层到协议层的完整认知很多人第一次拿到9针串口线的时候脑子里想的都是“插上去、打开串口助手、看数据”结果折腾一下午连个字符都没收到。问题出在哪儿绝大多数情况不是代码写错了而是对9针串口这个物理接口本身缺乏基本认知。9针串口学名DB9连接器是RS232串行通信最常见的物理载体。它看起来简单9个针脚排成两排但每一个针脚都有明确的定义和用途接错一根线通信就彻底废了。先把这个接口的针脚定义说清楚。DB9公头和母头的针脚编号是镜像的这一点新手特别容易搞混。公头带针的那一端面对你的时候上面一排从左到右是1到5下面一排从左到右是6到9。母头带孔的那一端面对你的时候上面一排从左到右是5到1下面一排从左到右是9到6。这个镜像关系导致很多人在焊线或者做转接头的时候把2脚和3脚接反了结果就是发送和接收对不上数据永远收不到。对于标准的RS232通信真正用到的核心针脚只有三个2脚是RXD接收数据3脚是TXD发送数据5脚是GND信号地。如果你只是做最简单的双向通信把这三根线接对就能跑起来。但这里有个关键点两台设备直连的时候A设备的TXD要接到B设备的RXDA设备的RXD要接到B设备的TXDGND对GND。这叫交叉连接。很多人下意识地觉得“2脚对2脚、3脚对3脚”才对结果就是两边都在发、两边都收不到。除了这三个核心针脚DB9还有几个在实际调试中经常被忽略但非常重要的针脚。4脚是DTR数据终端就绪6脚是DSR数据设备就绪7脚是RTS请求发送8脚是CTS清除发送。这四个针脚构成了硬件流控的基础。在一些老式设备或者工业设备上如果不对这四个针脚做处理通信根本建立不起来。我遇到过一台工业称重仪表串口参数怎么调都不通最后发现是设备固件里默认开启了硬件流控必须把RTS和CTS短接或者在上位机软件里正确配置流控模式才能正常收数。1脚是DCD载波检测9脚是RI振铃指示这两个在调制解调器时代很重要现在基本用不到了。但在某些特殊场景下比如调试老式工控设备DCD的状态可能会影响设备的发送行为。如果设备一直不发送数据可以量一下1脚的电平状态确认设备是否在等待载波信号。理解这些针脚定义之后还要建立一个概念RS232的电平标准和TTL电平是完全不同的。RS232用负逻辑逻辑1是-3V到-15V逻辑0是3V到15V。而单片机、FPGA这些芯片的UART接口是TTL电平逻辑1是3.3V或5V逻辑0是0V。所以你不能把单片机的TX直接接到DB9的2脚上中间必须经过电平转换芯片比如MAX3232、SP3232这类。我见过有人直接把STM32的TX接到DB9上结果要么收不到数据要么直接把芯片的IO口打坏。这个坑一定要避开。还有一个经常被忽视的点DB9接口本身只是物理连接器它上面跑的协议可以是RS232也可以是RS485甚至是RS422。RS485用的是差分信号通常用DB9的1脚和2脚或者3脚和8脚来传输A和B信号具体定义看设备手册。所以拿到一个DB9接口第一件事不是插线而是确认它到底是RS232还是RS485两者的电气特性、接线方式、传输距离完全不一样。RS232理论传输距离15米左右RS485可以到1200米搞混了就会出现“短距离能通、长距离丢包”的诡异现象。2. 串口调试工具的选择逻辑与参数配置的底层原理工欲善其事必先利其器。串口调试这件事工具选对了能省一半时间。市面上串口调试助手多如牛毛从最基础的SSCOM、XCOM到功能更全的ComAssistant、串口猎人再到跨平台的minicom、picocom还有集成在IDE里的PlatformIO串口监视器、Arduino串口监视器。每个工具都有自己的脾气关键是要知道什么场景下用哪个。如果你是在Windows下做快速验证SSCOM和XCOM是最顺手的选择。它们体积小、启动快、支持HEX和ASCII切换、支持定时发送、支持多条快捷发送指令。我个人的习惯是手头常备一个SSCOM用来做最基础的收发测试。但SSCOM有个问题它不支持脚本自动化如果你需要做批量测试或者协议解析就得换工具。ComAssistant在这方面更强一些支持Lua脚本可以写一些简单的自动化逻辑。如果你是在Linux环境下开发minicom和picocom是标配。minicom功能全但操作逻辑有点反人类退出是CtrlA然后按X第一次用的人基本都要查手册。picocom更轻量命令行参数清晰适合在脚本里调用。在Ubuntu下查看串口设备用ls /dev/ttyUSB*或者ls /dev/ttyACM*如果设备是原生串口通常是/dev/ttyS0这种。这里有个坑Linux下普通用户默认没有串口设备的读写权限需要把自己加到dialout组里命令是sudo usermod -a -G dialout $USER然后重新登录生效。很多人第一次在Linux下用串口看到“Permission denied”就懵了其实就是权限问题。在macOS下串口设备通常是/dev/tty.usbserial-XXXX或者/dev/cu.usbserial-XXXX。注意tty.和cu.的区别tty.是等待DCD信号才打开cu.是立即打开。调试的时候用cu.更省事不然设备不发DCD信号串口根本打不开。参数配置是串口调试的核心。波特率、数据位、停止位、校验位这四个参数必须和对方设备完全一致错一个就全是乱码或者收不到数据。波特率最常见的是9600和115200工业设备上19200、38400也很常见。数据位通常是8位停止位1位校验位无。但有些老设备用7位数据位、偶校验、2位停止位这种组合在电表、PLC上还能见到。这里要解释一下为什么参数必须一致。串口通信是异步通信没有时钟线收发双方靠约定的波特率来采样数据。如果发送方用9600接收方用115200接收方采样速度是发送方的12倍采到的数据完全对不上表现出来就是乱码。数据位和停止位定义了帧结构发送方在起始位之后发送数据位然后发送停止位。如果接收方不知道数据位是7位还是8位它就无法确定停止位的位置帧同步就会失败。校验位的作用是检错不是纠错。奇偶校验只能发现奇数个位错误不能发现偶数个位错误也不能纠正错误。所以现在大多数场景下都用无校验靠上层协议来保证数据完整性。但在一些电磁环境复杂的工业现场偶校验还是能起到一定的过滤作用。流控是另一个容易出问题的配置。流控分硬件流控RTS/CTS和软件流控XON/XOFF。硬件流控靠4脚和8脚的电平来协调发送节奏软件流控靠发送特定字符0x11和0x13来控制。如果设备开启了硬件流控而上位机没开设备可能一直不发送数据因为它认为上位机没准备好接收。反过来如果上位机开了硬件流控设备没开上位机可能一直不发送因为它没收到CTS信号。我调试一台激光测距仪的时候就遇到过这个问题设备手册上写的是“默认开启硬件流控”但实际固件里流控是关闭的导致我按手册配置后反而收不到数据。后来用示波器量了RTS和CTS的电平才发现设备根本没驱动这两个针脚。所以手册和实际固件不一致的情况是存在的遇到问题要敢于用仪器去验证。3. 从零跑通一次9针串口通信的完整实操链路光说不练假把式。下面我以一台Windows电脑和一块STM32开发板为例把整个串口通信的链路完整走一遍。这个链路涵盖了硬件连接、驱动安装、参数配置、数据收发、问题排查的全过程你照着做一遍基本就能掌握9针串口调试的核心技能。3.1 硬件连接USB转串口模块与DB9的对接现在大多数笔记本电脑没有原生DB9接口所以需要一个USB转串口模块。市面上最常见的是CH340芯片和CP2102芯片的模块。CH340便宜但驱动在Win7下有时候需要手动装CP2102贵一点但驱动兼容性好Win7、Win10、Win11基本免驱。我建议手头备一个CP2102的模块省去装驱动的麻烦。USB转串口模块出来的是TTL电平要接到DB9接口上有两种方式。一种是模块本身带DB9公头直接插设备另一种是模块出来是杜邦线需要自己接到DB9的针脚上。如果是后者接线规则是模块的TXD接DB9的2脚RXD模块的RXD接DB9的3脚TXD模块的GND接DB9的5脚GND。注意这里是交叉接法模块的发送接设备的接收模块的接收接设备的发送。如果设备是RS485接口那就不能用TTL直接接。RS485是差分信号需要485转TTL模块或者USB转485模块。USB转485模块出来通常是A和B两个端子A接设备的AB接设备的B。有些设备的DB9接口上RS485的A和B定义在1脚和2脚有些在3脚和8脚一定要查手册确认。RS485总线两端还需要接终端电阻通常是120欧姆用来消除信号反射。如果通信距离短、波特率低不接终端电阻也能凑合但长距离高速率下不接误码率会明显上升。3.2 驱动安装与端口号确认硬件接好之后把USB转串口模块插到电脑上。打开设备管理器看“端口”下面有没有新增一个COM口。如果有黄色感叹号说明驱动没装好。CH340的驱动可以去芯片厂商官网下载CP2102的驱动在Silicon Labs官网有。装完驱动重新插拔一下端口号就出来了。这里有个细节端口号是系统分配的不同USB口插同一个模块端口号可能不一样。所以每次换USB口都要重新确认端口号。在代码里写死COM3这种换台电脑就跑不起来。我一般会在代码里做成可配置的或者用串口枚举的方式自动查找。Win7下查看串口被哪个程序占用是个经典问题。设备管理器只能看到端口号看不到占用进程。这时候可以用微软的Process Explorer工具按CtrlF搜索“COM3”就能找到哪个进程打开了这个串口。或者用命令行工具handle.exe命令是handle.exe COM3。如果串口被占用打开串口助手会提示“拒绝访问”或者“端口已被占用”。遇到这种情况先关掉所有可能占用串口的软件包括串口助手、IDE的串口监视器、虚拟机等。3.3 串口助手参数配置与首次收发测试打开SSCOM或者XCOM选择对应的COM口配置参数波特率115200数据位8停止位1校验位无流控无。点击“打开串口”。如果打开失败先检查端口号对不对再检查是不是被占用了。打开成功后在发送区输入“Hello”点击发送。如果设备端有回显接收区就能看到“Hello”。如果没有回显先确认设备端是否在运行接收程序。我习惯先用一个最简单的回环测试把USB转串口模块的TXD和RXD短接然后发送数据看接收区能不能收到一样的数据。如果能收到说明模块和电脑这边没问题问题在设备端如果收不到说明模块或者驱动有问题。这个回环测试是排查串口问题的第一步能快速定位问题在哪一侧。很多人一上来就怀疑设备代码结果折腾半天发现是模块坏了或者驱动没装好。3.4 STM32端串口初始化的关键代码与DMA接收配置设备端以STM32F103为例用HAL库初始化串口。关键代码如下UART_HandleTypeDef huart1; void MX_USART1_UART_Init(void) { huart1.Instance USART1; huart1.Init.BaudRate 115200; huart1.Init.WordLength UART_WORDLENGTH_8B; huart1.Init.StopBits UART_STOPBITS_1; huart1.Init.Parity UART_PARITY_NONE; huart1.Init.Mode UART_MODE_TX_RX; huart1.Init.HwFlowCtl UART_HWCONTROL_NONE; huart1.Init.OverSampling UART_OVERSAMPLING_16; if (HAL_UART_Init(huart1) ! HAL_OK) { Error_Handler(); } }发送数据用HAL_UART_Transmit接收数据用HAL_UART_Receive。但这两个函数是阻塞式的在实际项目中很少用。更常用的方式是中断接收或者DMA接收。DMA接收可以大大降低CPU占用率特别是在高波特率下。配置DMA接收的步骤在CubeMX里使能USART1的DMA接收通道模式选Normal或者Circular。Normal模式下DMA接收完指定长度的数据就停止需要重新启动Circular模式下DMA会循环填充缓冲区适合连续接收。然后调用HAL_UART_Receive_DMA(huart1, buffer, length)启动接收。这里有一个STM32F103使用HAL库串口DMA接收首帧丢失的经典问题。原因是DMA启动之前串口可能已经收到了数据但DMA还没准备好导致第一个字节丢失。解决办法是在启动DMA之前先清除接收标志位或者用空闲中断IDLE来触发DMA接收。空闲中断的思路是串口总线空闲时触发中断在中断里计算接收到的数据长度然后处理数据。这种方式不需要预先知道数据长度特别适合不定长协议。void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); HAL_UART_DMAStop(huart1); uint8_t len BUFFER_SIZE - __HAL_DMA_GET_COUNTER(huart1.hdmarx); // 处理接收到的len个字节 HAL_UART_Receive_DMA(huart1, buffer, BUFFER_SIZE); } }这段代码是实战中非常常用的模式配合DMA和空闲中断可以稳定接收不定长数据。3.5 数据收发的验证与常见异常处理设备端和电脑端都配置好之后就可以做双向通信测试了。电脑发送“ABC”设备收到后原样返回电脑接收区显示“ABC”。如果收到的数据不对按以下顺序排查先看波特率是否一致。如果接收区显示的是乱码但数据长度对基本就是波特率不匹配。如果数据长度都不对可能是数据位、停止位、校验位配置不一致。再看接线是否正确。TXD和RXD是否交叉连接GND是否共地。如果GND没接通信可能时好时坏或者完全不通。然后看电平是否匹配。如果设备是RS232电平电脑端是TTL电平中间没有电平转换芯片那肯定不通甚至可能损坏设备。最后看流控配置。如果设备开启了硬件流控电脑端也要开启或者把设备的RTS和CTS短接。我遇到过一次特别诡异的情况设备发送数据电脑能收到但电脑发送数据设备收不到。排查了半天发现是设备的RXD针脚虚焊了时通时不通。所以硬件问题不能忽视该用万用表量通断的时候不要偷懒。4. 进阶场景RS485组网、DMA优化与跨平台串口调试掌握了基础的9针串口调试之后实际项目中还会遇到更复杂的场景。这一部分聊聊RS485组网、DMA接收优化、以及在不同平台上做串口调试的经验。4.1 RS485总线上下拉电阻的选择与计算RS485组网是工业现场最常见的多机通信方式。一条总线上可以挂多个设备通过A和B两根差分线传输信号。但RS485总线有个问题当总线上所有设备都不发送数据时A和B之间的差分电压是不确定的可能导致接收器误判为有数据。所以需要在总线上加偏置电阻把A拉到高电平B拉到低电平确保空闲时差分电压大于200mV。偏置电阻的计算需要考虑终端电阻和总线上的设备数量。假设总线两端各有一个120欧姆的终端电阻并联后等效60欧姆。为了让差分电压大于200mV偏置电阻的取值需要满足Vab Vcc * Rterm / (Rterm Rbias) 0.2V。如果Vcc是5VRterm是60欧姆那么Rbias 60 * (5 - 0.2) / 0.2 1440欧姆。通常取560欧姆到1k欧姆之间。上拉电阻接在A和Vcc之间下拉电阻接在B和GND之间。实际调试中如果通信不稳定可以先量一下空闲时A和B之间的电压。如果小于200mV就减小偏置电阻如果功耗太大就增大偏置电阻。但偏置电阻不能太小否则驱动能力不够的设备可能拉不动总线。我一般会先用1k欧姆试不行再换560欧姆。RS485组网还有一个常见问题总线拓扑。RS485必须是手拉手的总线结构不能星型或者树型。如果分支太长信号反射会很严重。分支长度一般不超过总线长度的1/10。如果现场布线已经定了没法改那就降低波特率或者加485中继器。4.2 串口DMA接收的缓冲区管理与丢包处理在高波特率下比如921600甚至更高中断接收可能来不及处理导致丢包。DMA接收是解决这个问题的标准方案。但DMA接收也有自己的坑。第一个坑是缓冲区溢出。如果DMA缓冲区满了但CPU还没处理新来的数据就会覆盖旧数据。解决办法是用双缓冲区Ping-Pong BufferDMA填一个缓冲区的时候CPU处理另一个。STM32的DMA支持双缓冲模式配置起来也不复杂。第二个坑是帧边界识别。DMA接收的是字节流没有帧的概念。如果协议是定长的好办按固定长度切分就行。如果协议是不定长的就需要靠空闲中断或者超时机制来切分帧。空闲中断的原理前面说过超时机制是设定一个定时器如果一段时间内没有新数据就认为一帧结束。第三个坑是DMA和中断的优先级。如果DMA中断优先级太低可能被其他中断打断导致数据处理不及时。我一般会把DMA中断优先级设得高一些但也不能太高否则会影响其他关键中断。在Linux下从串口接收数据丢失通常是因为串口驱动的缓冲区太小或者应用程序读取不及时。可以用stty -F /dev/ttyUSB0查看当前串口配置用cat /proc/tty/driver/serial查看串口状态。如果发现overrun计数在增加说明缓冲区溢出了。解决办法是增大驱动缓冲区或者提高应用程序的读取频率。在应用层可以用select或者epoll来监听串口数据一旦有数据就立即读取。4.3 跨平台串口调试Windows、Linux、macOS的差异与应对不同操作系统下串口调试的差异主要体现在设备命名、权限管理、工具链上。Windows下设备名是COMx权限管理比较简单但端口号不固定。Linux下设备名是/dev/ttyUSBx或/dev/ttySx需要dialout组权限。macOS下设备名是/dev/tty.usbserial-xxxx或/dev/cu.usbserial-xxxx用cu.前缀更省事。在虚拟机里配置串口比如VMware或者VirtualBox需要把物理串口映射到虚拟机。VMware下是在虚拟机设置里添加串口选择“使用物理串口”然后选择对应的COM口。VirtualBox下是在设置里启用串口端口模式选“主机设备”然后选择COM口。注意虚拟机里的串口参数要和主机上一致否则可能映射失败。在VSCode里用PlatformIO开发ESP32或者STM32串口监视器是集成好的。PlatformIO的串口监视器配置在platformio.ini里可以设置monitor_speed、monitor_rts、monitor_dtr等参数。ESP32S3开发时串口输出默认是USB CDC需要在platformio.ini里配置-D ARDUINO_USB_CDC_ON_BOOT1否则串口监视器看不到输出。这个坑我踩过当时以为板子坏了后来查了文档才知道是USB CDC没使能。Arduino框架下串口监视器的波特率要和Serial.begin()里的参数一致。如果串口监视器显示乱码先检查波特率。Arduino串口监视器还有一个“自动滚动”选项如果关掉了新数据不会自动显示看起来就像卡住了。4.4 串口封装与代码复用从裸机到跨平台在实际项目中串口代码往往需要在不同平台之间复用。比如同一套协议可能在STM32上跑也可能在Linux上跑还可能在上位机C#程序里跑。这时候就需要对串口操作做一层封装。封装的思路是定义统一的接口打开、关闭、发送、接收、设置参数。底层根据平台不同调用不同的API。在STM32上底层是HAL库在Linux上底层是termios在Windows上底层是CreateFile和ReadFile。上层协议解析代码完全复用。C#串口通信在Windows上位机开发中很常见。System.IO.Ports.SerialPort类提供了完整的串口操作接口。需要注意的是C#的串口接收事件是在后台线程触发的更新UI需要Invoke到主线程。另外串口关闭时要先取消事件订阅否则可能抛异常。Python下用pyserial做串口调试也很方便。serial.Serial类支持跨平台打开串口、读写数据都很简单。pyserial还支持in_waiting属性可以查看接收缓冲区里有多少字节方便做非阻塞读取。不管用什么语言串口操作的核心逻辑是一样的配置参数、打开端口、读写数据、处理异常、关闭端口。把这套逻辑封装好换平台的时候只需要改底层驱动上层代码基本不用动。5. 那些年我踩过的串口坑从烧写失败到数据乱码的排查实录串口调试这件事理论归理论实际动手的时候总会遇到各种意想不到的问题。这一部分我把自己这些年踩过的坑整理出来每个坑都附上排查思路和解决办法希望能帮你少走弯路。5.1 串口烧写失败BOOT引脚、复位时序与工具配置用串口给STM32烧写程序是很多开发板的标准操作。但串口烧写失败的概率相当高原因通常集中在几个地方。首先是BOOT引脚。STM32的BOOT0和BOOT1决定了启动模式。要从串口烧写BOOT0必须接高电平BOOT1接低电平然后复位。很多开发板上有跳线帽但跳线帽的位置可能标得不清楚。我见过一块板子BOOT0的跳线帽插在“0”的位置但丝印印反了导致怎么都进不了Bootloader。后来用万用表量了BOOT0对地的电压才发现问题。其次是复位时序。串口烧写工具比如FlyMcu在连接的时候会先拉低DTR和RTS控制开发板复位。如果开发板的复位电路和工具不匹配可能复位不成功。有些开发板需要手动按复位键有些需要改工具的复位模式。FlyMcu里有一个“DTR低电平复位RTS高电平进Bootloader”的选项大部分板子用这个配置就行。如果不行试试“RTS低电平复位DTR高电平进Bootloader”。还有是串口被占用。烧写的时候串口助手必须关掉否则烧写工具打不开串口。这个坑很基础但忙起来的时候经常忘。最后是波特率。串口烧写的波特率通常比通信波特率低常见的是115200或者57600。如果烧写工具和Bootloader的波特率不一致会一直同步失败。STM32的Bootloader通常会自动检测波特率但有些国产芯片的Bootloader只支持固定波特率需要查手册确认。5.2 数据乱码的三种典型原因与逐层排查方法数据乱码是串口调试中最常见的问题没有之一。乱码的表现形式有好几种每种对应的原因不同。第一种乱码接收到的全是0x00或者0xFF。这种通常是接线问题。TXD和RXD没交叉或者GND没接或者电平不匹配。如果接收到的全是0x00可能是RXD被拉低了全是0xFF可能是RXD被拉高了。用万用表量一下RXD对GND的电压空闲时应该是高电平TTL或者负电压RS232。第二种乱码接收到的数据有规律地错位。比如发送“12345”收到“23451”或者“51234”。这种通常是波特率不匹配导致的采样错位。波特率差一点点短时间内看不出来数据量大了就会累积误差导致帧同步丢失。解决办法是确保双方波特率完全一致晶振精度要够。有些低成本设备的晶振误差比较大高波特率下容易出问题可以降低波特率试试。第三种乱码接收到的数据偶尔错几个字节。这种通常是电磁干扰或者地环路导致的。RS485总线在工业现场容易受干扰可以加屏蔽双绞线或者加磁环。地环路问题在多台设备共地的时候容易出现可以用隔离型RS485模块把地隔开。排查乱码问题的顺序是先确认接线再确认参数然后确认电平最后考虑干扰。不要一上来就怀疑代码大部分乱码问题都是硬件或者配置问题。5.3 串口被占用、驱动异常与系统层面的疑难杂症串口被占用这个问题在Windows下特别常见。你明明关掉了串口助手但再打开的时候提示“端口已被占用”。这时候可能是后台还有进程没退出或者驱动状态异常。排查方法前面说过用Process Explorer或者handle.exe找占用进程。如果找不到可以试试在设备管理器里禁用再启用串口设备或者直接卸载驱动再重新扫描。有时候是USB转串口模块的驱动挂了重新插拔一下就好。Win7下CH340驱动安装失败是个经典问题。CH340的驱动在Win7下有时候会因为数字签名问题装不上。解决办法是关闭驱动签名强制或者用旧版本的驱动。如果实在装不上换CP2102模块省心。Linux下串口权限问题前面说过把自己加到dialout组。但有时候加了组还是不行可能是udev规则的问题。可以写一个udev规则给特定VID和PID的串口设备固定权限和别名。比如SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666, SYMLINKttyUSB_CH340这样插上CH340模块就会自动创建一个/dev/ttyUSB_CH340的软链接权限是666任何用户都能读写。这个技巧在多设备调试的时候特别有用不用每次去查设备号。5.4 从一次“通信正常但数据不对”的案例看协议层排查最后分享一个比较隐蔽的案例。有一次调试一台传感器串口参数配置正确接线正确收发都正常但解析出来的数据就是不对。传感器返回的是二进制数据我用串口助手以HEX模式查看发现数据帧的长度和手册上写的不一样。排查过程是这样的先确认波特率、数据位、停止位、校验位都没问题。然后用示波器抓了一下波形发现传感器实际发送的数据帧比手册上多了两个字节。仔细看手册发现手册上写的是“数据帧长度12字节”但实际固件版本是“数据帧长度14字节”多了两个字节的保留字段。手册和固件不一致导致解析错位。这个案例说明串口调试不能完全依赖手册要用实际抓到的数据来验证。串口助手是最基本的工具但有时候需要更强大的工具比如逻辑分析仪或者示波器来抓取原始波形分析时序和电平。逻辑分析仪可以解码UART协议直接看到每个字节的值比串口助手更底层更适合排查协议层的问题。另外协议解析的时候要注意字节序。大端和小端的问题在串口通信中很常见。传感器返回的4字节浮点数可能是大端排列也可能是小端排列。如果解析出来是乱码先检查字节序。可以用一个已知的值来测试比如发送1.0看返回的字节是什么然后反推字节序。串口调试这件事说到底就是细心加经验。参数、接线、电平、协议一层一层排查总能找到问题。最怕的是跳步比如没确认接线就去改代码没确认参数就去怀疑硬件。按部就班地来大部分问题都能在半小时内定位。
