纸飞机串口调试助手是一款典型的桌面串口调试工具但它和普通串口助手最不一样的地方是支持自定义 HEX 协议。换句话说你不需要每次手动拼报文、手算校验码而是可以先把协议帧定义好帧头在哪、命令字在哪、长度字段在哪、校验用哪种算法之后每次发指令只需要填几个关键值工具会自动生成完整 HEX 帧。这个能力对搞嵌入式、单片机、传感器、PLC 联调、产线测试的人来说非常实用。这篇文章会从实际使用角度把环境准备、协议配置、单条收发、批量测试和问题排查完整拆一遍。我在实际调设备时最深的感受是串口调试助手本身不难用难的是协议一复杂人就容易在拼帧和算校验上出错。尤其当数据域长度、CRC 算法、大小端顺序稍微变一下手工拼出来的报文基本没法保证正确。纸飞机这类支持自定义 HEX 协议的助手真正有价值的不是“能发十六进制”而是“能把协议规则固化成模板让工具替你完成重复劳动”。1. 先搞清楚普通串口助手不够用的原因再理解自定义 HEX 协议的价值1.1 普通串口助手的典型局限很多串口调试助手都能做到以下基础功能选择 COM 口、设置波特率、打开串口、在发送区输入内容、点击发送然后在下方的接收区查看设备返回的数据。这个流程对简单的串口通信来说已经够用比如给一个串口模块发一条 AT 指令收一句返回文本。但遇到稍微正式一点的设备协议问题就来了。第一发送内容没有帧结构概念。你输入一段 HEX比如AA 55 01 02 00 64 3C工具只是把这串十六进制字节发出去它不知道哪一字节是帧头、哪一字节是命令、哪一字节是校验。你需要自己按照协议文档拼好这一串多一个字节、少一个字节设备就不响应。第二校验码需要手工计算。常见的累加和、异或校验、CRC16、CRC32如果每次都靠手算或用第三方工具算效率很低而且容易错。CRC16 还涉及初值、多项式、输入反转、输出反转、大小端输出等细节手工算错一步整个报文报废。第三接收区只是原始数据展示。设备返回的数据到了接收区通常只做 HEX 或 ASCII 显示。帧是否完整、数据域是否合法、校验是否正确需要自己人眼判断。一次测试发几十条指令、收几十条回包每一条都人眼核对非常消耗精力。第四批量测试和重复性任务比较弱。很多助手支持定时循环发送但往往只是把同一个发送内容重复发没有“这一条指令发完等设备超时判断再发下一条”的完整测试逻辑。所以普通串口助手适合做快速连通性测试但不太适合做协议联调。1.2 自定义 HEX 协议究竟解决了什么纸飞机串口调试助手这类工具核心就是把协议规则交给工具去管理。你需要做的不是每次都拼一条完整报文而是先在工具里定义一次协议模板之后发指令时只填变化的部分。一个常见设备控制协议可以这样描述帧头固定AA 552 字节设备地址1 字节比如0x01功能码1 字节比如0x01表示启动、0x02表示停止数据长度1 字节表示后面数据区的字节数数据区N 字节存放具体参数校验字段1 字节累加和从帧头开始累加到数据区结束如果不用自定义协议你每次都要按文档算好长度、算好校验然后把整段报文复制到发送框。用自定义协议之后只需要选好协议名称填入设备地址、功能码、数据内容工具自动计算长度和校验生成完整报文。接收端的价值同样明显。工具可以按协议自动切帧收到完整的帧后再显示并自动校验。校验不通过的帧可以直接标记出来不需要人眼去看。这在连续接收大量数据时非常有用。这个功能适合的人群很明确做单片机开发、嵌入式板卡联调、传感器模块调试、PLC 通信测试、电源或电机等设备测试的工程师以及正在学习串口通信的新手。如果你只是临时给串口模块发几条普通文本那自定义协议功能可能用不上但只要你手里的设备有明确帧格式就值得花十几分钟把协议模板配好。2. 运行环境与启动准备先把串口通道打通再进协议配置2.1 系统和驱动准备纸飞机串口调试助手通常是 Windows 桌面程序也会有一些跨平台版本或类似界面的工具。无论具体形态是什么第一步都一样确认系统能识别到串口设备。常见情况是使用 USB 转串口模块比如常见的 CH340、CP2102、FT232 芯片。这时候需要先安装对应驱动。设备插上后如果设备管理器里出现一个带感叹号的未知设备说明驱动没装到位如果出现“COM3”或“COM5”之类的端口号说明识别成功。确认端口的步骤打开设备管理器。展开“端口(COM 和 LPT)”。查看新增的 COM 号比如 COM3、COM7。如果插上设备但完全没反应先换一条 USB 线再换一个 USB 接口最后考虑驱动问题。使用软件时建议右键选择“以管理员身份运行”。否则某些精简系统或安全软件可能导致串口打开失败。这种问题不一定是软件问题而是权限不足。2.2 串口参数与连接检查打开纸飞机串口调试助手后界面一般分为几个区域串口设置区、发送区、接收区、协议配置区。串口设置区通常包含以下参数参数常见值注意事项波特率9600、115200必须和设备一致否则收到的全是乱码数据位8常见的设备默认是 8 位停止位1多数设备使用 1 位停止位校验位None也有设备使用 Even、Odd 或 Mark流控None很多设备不使用流控配置成 Hardware 可能导致通信异常如果不知道设备参数先查设备手册查不到就用最常见的115200, 8, N, 1试再用9600, 8, N, 1试。不要把大量时间耗在猜参数上先确定能收到内容再微调。在正式配置协议之前建议做一次回环测试。回环测试就是把串口模块的发送端 TXD 和接收端 RXD 短接或者用一根导线把串口助手的发送引脚和接收引脚短接。这样发送区发出的数据会被接收区原样收到。如果回环测试能通说明软件、驱动、端口链路都没有问题如果回环都不通先解决基础链路再进协议配置。回环测试时可以先在发送区输入AA 55 01 02 03选择 HEX 发送点击发送看接收区是否原样显示AA 55 01 02 03。这个步骤看起来简单但能排除掉一半以上的通信问题。我一般会先做这一步再连真实设备避免后面把软件配置问题误判成设备故障。3. 自定义 HEX 协议配置的完整流程从画帧结构到保存模板3.1 先画协议帧结构图很多人拿到串口调试助手后第一反应是打开软件急着在界面上找“自定义协议”按钮。但正确顺序是先看协议文档把帧结构画清楚。你连协议格式都没理清楚工具界面再智能也没法替你决定哪一字节是长度、哪一字节是校验。我习惯用一张简单的表格来描述协议帧字节偏移01234567含义帧头1帧头2设备地址功能码数据长度数据1数据2校验以这个表格为例帧头固定为AA 55。设备地址固定为01。功能码有具体含义发送时选择。数据长度表示第 5 字节到第 6 字节的数据区字节数这里为 2。校验为累加和范围从第 0 字节到第 6 字节。如果换成 CRC16校验字段会占 2 字节可能在数据区之后还要区分高字节在前还是低字节在前。这些信息必须从协议文档里确认不能靠猜。纸上画完帧结构后再去软件里配置效率会高很多。3.2 在软件中新建协议与字段配置纸飞机串口调试助手的具体界面版本可能不同但功能入口一般叫“自定义协议”“协议管理”“自定义报文”或“协议模板”。进入后通常需要完成以下配置给协议起一个名称比如“电机控制协议”。选择发送方式为 HEX。配置帧头。输入固定字节比如AA 55。帧头通常放在协议配置的“起始标识”或“帧头”字段。配置地址字段。选择“固定值”或“变量”固定值填01变量则在发送时填。配置功能码字段。一般做成枚举或变量比如01显示为“启动”02显示为“停止”这样发送时直接在界面上选择不需要记十六进制值。配置长度字段。指定长度字段在第几字节并确定它表示后面数据区的长度还是整个帧的长度。常见的是“数据区长度”也就是从数据区第 1 个字节到最后一个字节的字节数。配置数据区。设置数据区的最大长度和内容类型。如果是纯参数可以做成若干个变量的组合。配置校验字段。选择校验位置、校验算法、计算范围。校验算法这一步最容易出问题。常见的选项有校验方式特点适用场景累加和校验对所有参与计算的字节求和取低 8 位简单控制协议异或校验所有字节异或得到 1 字节校验值简单通信协议CRC162 字节校验更可靠算法变体多Modbus、工业设备CRC324 字节校验可靠性高文件传输、固件协议如果软件里提供了 CRC16 的多个参数配置项比如多项式、初值、输入反转、输出反转你需要从协议文档中找到具体定义。比如常见 Modbus CRC16 的多项式是0xA001初值是0xFFFF低字节在前。如果配错了工具计算出的校验码和真实设备要求不一致设备会一直拒绝通信。配置字段时建议借助“第几字节”“偏移量”这类概念。从协议帧的起始字节开始算第 0 字节是帧头第一个字节第 1 字节是帧头第二个字节依此类推。这样配置长度字段位置和校验位置时不会乱。3.3 保存协议模板和自检配置完成后纸飞机串口调试助手一般会提供“保存模板”或“导出配置”功能。建议第一时间保存并且最好导出成独立文件比如 JSON 或 XML 格式。原因很简单软件升级、卸载重装、换电脑时协议模板不会自动跟着走。没有备份下次重新配置一遍很浪费时间。保存之后做一个协议自检。有些工具会提供一个“示例帧”或“预览”功能选择协议后填一组测试数据看生成的报文是否符合你的预期。比如前面说的协议模板如果我填设备地址为01、功能码为01、数据区为00 64那么生成的报文应该是帧头AA 55地址01功能码01数据长度02数据区00 64累加和校验AA 55 01 01 02 00 64的结果取低 8 位如果工具生成的报文与手工计算一致说明协议模板配置正确。如果报文里长度字段或校验字段不对先回去检查字段位置和计算范围不要急着接设备。4. 用配置好的协议模板做单条指令收发4.1 发送一条指令时应该看到什么协议模板配置完成并保存后回到主发送界面。这时候发送区不再是普通的自由输入模式而是根据协议模板动态生成了输入项设备地址、功能码、数据参数等。以电机控制指令为例选择协议模板“电机控制协议”设备地址填01功能码选择“启动”数据参数填00 64点击“生成报文”或“发送”工具自动生成完整 HEX 帧正常情况下发送日志或发送区会显示类似AA 55 01 01 02 00 64 XX的完整报文其中XX是工具自动计算出的校验值。这条链路的价值在于你不再需要每次手动计算长度和校验。你只需要关注业务参数比如功能码是启动还是停止、数据参数是多少。工具负责把协议层所有固定规则处理好。但是要注意自动生成报文不等于设备一定会正确响应。设备能不能执行取决于报文内容是否符合设备协议。如果设备没反应先确认协议定义有没有弄错再确认设备当前状态是否允许执行该指令。4.2 接收端的自动解析和帧切分纸飞机串口调试助手另一个比较实用的点是接收端解析。启用协议解析模式后接收区不再是一堆连续 HEX 字节而是按帧结构拆分后的结果。比如设备连续返回多帧数据如果每帧是AA 55 01 04 01 02 03 04 0F开启协议解析后接收区会按帧头和长度字段自动切分把不完整的半包、粘包区分开。这样你能快速判断设备是否连续返回了预期帧数而不是在一大串字节里用眼睛找帧头。判断一次收发是否正常可以从三个点看发送是否生成了完整帧。接收区是否能按协议切出完整帧。接收帧的校验码是否通过。如果以上三点都正常说明串口链路和协议配置基本没问题。如果显示接收到了数据但无法切帧检查帧头配置和长度字段定义。4.3 如何验证协议模板真的正确我建议先用回环方式做一次协议验证而不是直接接真实设备。把 TXD 和 RXD 短接发送一条配置好的协议帧接收区应该原样返回同一帧。此时校验字段是工具自动计算的回环能证明工具生成的报文是完整且一致的。接着再接真实设备发送一条功能最简单的指令比如“读取设备状态”“查询设备版本”。这些指令通常不需要设置复杂参数返回也比较固定适合用来验证整体链路。如果真实设备无响应排查顺序是先看发送日志里报文是否完整。用另一台串口调试助手对比抓包。确认设备的串口参数是否匹配。确认设备地址是否正确。确认功能码和参数是否符合设备文档。不要一开始就怀疑协议模板有问题。实际上很多问题出在参数匹配和电气连接上。5. 批量发送、循环测试与数据导出的实战细节5.1 循环发送不要一上来就开满很多串口调试助手支持循环发送纸飞机这类工具自然也有。循环发送在长时间稳定性测试中很有用比如让设备连续跑一个小时观察设备是否掉线、通信是否中断、内存是否泄漏。但不要一上来就把间隔时间调到最小比如 1ms、5ms。原因有两个第一很多设备内部处理串口数据需要时间命令发太快设备可能来不及处理导致丢指令或状态异常。 第二工具和操作系统串口缓冲有限发送间隔过短加上数据量过大容易出现丢数据、界面卡顿、发送队列堆积。我一般建议先用 100ms 间隔试发 100 条观察接收区是否每条都有响应。稳定之后再尝试缩短到 50ms、20ms直到出现丢包或设备异常再往回调。这个“找边界”的过程才是循环发送的正确用法。循环发送时还需要注意终止条件。不要设置成“无限发送”却无人值守除非你已经确认设备状态稳定且日志能完整记录。否则一旦设备异常日志会持续增长浪费磁盘空间也增加排查难度。5.2 批量指令脚本与条件判断如果测试场景不是“同一条指令重复发”而是“按顺序执行多条指令”就需要批量指令功能。批量指令的常见组织方式每行一条指令。指令可以是手动填写的完整 HEX 报文也可以是协议模板中的某个命令。每条指令之间可以设置独立延时。如果设备有响应可能会配置“等待响应超时”时间。批量执行时要重点看两件事失败重试和指令日志。某条指令发送后设备没响应是直接跳过继续下一条还是自动重试这个逻辑必须在测试前确认清楚。如果设备在测试过程中可能出现瞬时超时而工具没有重试机制那么整批测试结果会有大量“失败”记录干扰判断。批量测试的日志应该包含每条指令的发送时间发送报文内容是否收到响应响应内容校验是否正确单条指令耗时如果工具支持导出日志优先导成 CSV 或文本文件方便后续分析和归档。5.3 日志和数据导出的必要性长时间测试之后接收区的数据不可能全在屏幕上保留。你需要依赖日志文件复盘。纸飞机串口调试助手如果提供日志记录功能建议在长测之前打开并设置日志文件存储路径。日志文件命名最好带时间戳比如20250120_1500_com3_test.log防止多次测试日志互相覆盖。日志文件要关注最大的问题不是文件体积而是文件增长过快导致磁盘空间写满。长测开始前先看一下目标磁盘剩余空间。如果日志包含收发原始数据几千帧也就几十 KB一般不会出问题但如果是高频收发几个小时日志文件可能上 GB这时候要考虑按小时切分日志或定期清理。6. 常见问题排查链路从端口、协议、日志逐层分析6.1 打不开串口打不开串口的现象通常是点击“打开串口”后弹出“打开失败”或“端口被占用”。排查顺序如下检查设备管理器里 COM 号是否还存在。检查软件是否以管理员身份运行。检查该 COM 口是否被其他软件占用比如多个串口工具同时打开同一个端口。重新插拔 USB 转串口模块看 COM 号是否变化。如果换过 COM 号回到工具里重新选择新 COM 号。不要反复点“重新打开”按钮。先确认端口状态再点打开不然问题可能被端口状态变化掩盖。6.2 串口已打开但发送后设备没响应串口能打开说明驱动和端口基本没问题。没响应要从这些方向排查接线是否正确。TXD 要接对方的 RXDRXD 接对方的 TXDGND 必须共地。串口参数是否匹配。波特率、数据位、停止位、校验位、流控任何一项不对都可能收不到。报文内容是否符合协议。帧头、地址、功能码、长度、校验逐字节核对。设备是否处于可响应状态。有些设备上电后需要先初始化或者需要先发送使能指令。排查时不要只盯着报文看。先拿示波器或逻辑分析仪看一下串口线上有没有实际波形。没有波形就看接线和发送端有波形再看内容和参数。6.3 校验和一直错误如果接收区显示“校验错误”或者设备一直回错误包优先检查校验配置计算范围。是只计算从帧头到数据区还是只计算从地址开始到数据区不同协议定义不同。校验字段位置。校验字节是否紧跟在数据区后面中间有没有固定填充字节。CRC16 的详细参数。多项式、初值、输入反转、输出反转、字节序这些参数必须和协议文档一致。数据长度字段是否影响了校验计算。有些协议的长度字段本身参与校验有些则不参与。如果协议文档没有明确说明 CRC 参数可以用一个已知正确的报文反推。比如设备手册给出了某条指令的完整报文里面包含正确 CRC 值你把这个报文逐字节输入到工具里观察工具的 CRC 计算方式能不能还原出同值。如果对不上调整参数再试。6.4 接收数据乱码或数据不完整乱码最常见的原因是波特率不匹配。发送端和接收端波特率只要差一点显示的字符就会完全乱掉。检查两端波特率是否一致。其次检查数据位和停止位。常见设备是 8 数据位、1 停止位、无校验。如果设备配置成 7 位数据位软件还按 8 位解析数据就会错乱。还要考虑信号干扰。USB 转串口模块如果线比较长或者周围有电机、电源模块等强干扰源可能导致误码。可以尝试降低波特率、使用带屏蔽的线材、缩短传输距离或者让设备接地更可靠。数据不完整则可能是半包。确认软件是否开启协议解析并检查长度字段是否配置正确。长度字段如果表示的数据区范围不对工具切帧时会把一帧拆成多帧或把多帧粘成一帧。6.5 批量跑久了卡死或无响应长时间循环发送后工具卡死原因通常不是“软件坏了”而是资源消耗和缓冲区问题。按以下顺序排查先看任务管理器里软件的内存和 CPU 占用。内存持续增长不下降说明有数据堆积或日志处理异常。检查接收缓冲区是否设置了上限。长时间高频率收发缓冲区如果不断增长界面刷新压力会非常大。检查日志文件大小。日志文件写入异常也可能阻塞软件主循环。降低发送频率。如果 50ms 间隔卡死试 200ms看是否还会卡死。如果问题始终出现把批量任务拆小比如每 500 条暂停一下或分批执行。长测前建议先跑 30 分钟短批次观察资源占用趋势。如果 30 分钟内内存和 CPU 没有异常再拉长到数小时甚至过夜。不要直接上来就开无限循环过夜万一软件卡住测试数据全废。7. 什么场景下值得用自定义 HEX 协议以及选型建议7.1 适合的人和场景自定义 HEX 协议模板功能并不适合所有使用者但对以下场景价值很高固定协议文档的设备需要反复发送不同参数的指令。产品测试阶段需要按测试用例批量执行多条指令。联调阶段需要快速验证协议字段变化对设备的影响。初学者学习串口通信协议想直观看到完整帧如何生成。如果你只是测试一个串口模块能不能正常透传随便用一个普通串口助手都行。但如果你想在同一个工具里完成协议定义、自动校验、接收解析、批量测试、日志导出那一款支持自定义 HEX 协议的助手会明显更顺手。我在实战中的建议是不要一上来就把所有指令配成模板。先挑 3 条最核心的指令配置比如“读取版本”“启动”“停止”。跑通完整链路后再扩展其他指令。这样能更快验证工具理解和设备协议是否一致也避免一次配置太多字段导致错误排查困难。7.2 与其他串口调试助手的简单对比市面上有很多串口调试助手比如经典的 SSCOM、轻量的 XCOM、网络型调试助手等。这些工具在基础串口收发上差别不大主要差异体现在协议模板、批量测试、自动化脚本和日志管理上。选择时可以看几个标准选择标准具体关注点协议模板是否支持自定义帧头、长度、校验是否支持 CRC16 参数配置批量执行是否能发一批指令支持失败重试、延时设置和结果记录接收解析是否能按协议切帧、自动校验、过滤干扰帧日志导出是否能导出带时间戳的收发日志使用门槛界面是否清晰协议配置是否需要写脚本纸飞机串口调试助手的亮点在于把“自定义 HEX 协议”作为核心能力来设计。实际使用时只要协议定义功能完整很多临时需求都可以通过协议模板解决不需要额外写脚本。7.3 落地时的几条实际建议第一协议模板保存文件做好版本管理。设备协议升级后不要直接在原模板上乱改最好另存一个新版本。否则过几天你会搞不清线上用的模板和当前协议文档是不是同一个版本。第二测试环境要固定。串口号、波特率、转接模块、接线方式、设备固件版本这些变量在长时间测试中尽量保持一致。一次只改一个变量才能定位问题。第三协议报错时先看日志再改参数。很多人一看设备无响应就急着调校验算法或帧头配置。其实先看日志里发送的报文内容再和设备文档逐字节对比很多时候毛病是地址填错或数据长度不对。第四如果软件支持“发送前预览”每次批量执行前先预览一条确认生成报文符合预期再开跑。批量任务一旦开始错一条可能连环错后面所有判断都会受影响。这类工具真正落地时最值得花时间的不是研究界面上所有高级按钮而是把协议定义、校验方式、日志链路三件事理清楚。协议模板配好一次后面整个联调周期都能受益。先把核心指令的单条收发做稳定再逐步扩展到批量、长时间测试整个流程会顺畅很多。