title: 串口发送为什么不能加延时?平台开发的五条守则、协议重引用的三步修复与 200 万波特率的线材门槛keywords: 上电事件, 分段播报, 串口延时限制, 协议重引用, WiFi日志波特率, 2000000, 播报指示, 白标小程序topic: 无gen_model: glm-5.3-flashversion: 1ai_review_cycles: 0created_at: 2026-09-10T18:39:07.000ZXX公司的 JX-12F 项目跨了三个月,产出了一批平台开发的高频规则:开机播报不能延时的替代方案、串口发送不能加延时、旧工程重新生成报错的协议排查、WiFi 日志的 2000000 波特率、无功放应用的播报指示。本篇把这组平台开发守则整理成文。守则一开机播报不能延时,上电事件分段播报替代需求:上电先播线路检测中,延时 3 秒再播下一段。直接在开机播报里加延时——“不能”。厂商给的替代方案:“搞个上电启动事件,然后后面添加分段播报的控制在那边延时”,“就不要用开机播报了”。结构:上电触发事件→第一段语音直接放→延时控制 3 秒→第二段语音。开机播报项可以关掉,“不影响上电触发事件”。守则:开机播报是固定动作不可编排,要时序编排就走事件链,开机播报退位让贤。守则二串口发送不能加延时,定时器外包把 4 个变量通过协议串口输出,在发送控制里加延时——失败。去掉延时立刻成功。客户自己总结:“看来,发送协议不能加延时哦”,解法我加多一个定时器,延时触发也行——厂商确认用定时器也可以。守则:协议发送控制内不可嵌延时,时序需求用外部定时器节点触发发送。守则三旧工程重新生成报错,先查协议几个月前的工程原样重新生成,报错且不提示具体配置。排查路径:厂商要工程 json 导出→客户自查想起协议问题,我好像改过了,增加了多个字节→厂商确认可能是这个问题,给出修复序列:“重新配置下协议,工程中重新引用,然后控制中重新选择协议,然后生成”。客户按此修复成功。守则:生成报错无提示时,优先排查协议(字节数变更最常见);修复要按改协议→工程重引用→控制重选三步走,只改协议不重引用等于没改。协议的用途也顺带明确:“协议主要是用于 WiFi 串口数据发出”——设备数据上小程序的通道。守则四WiFi 日志 2000000 波特率,串口线要撑得住OTA 失败排查,WiFi 模块日志的读取配置:“WiFi 模块烧录口,串口助手看,波特率 2000000,不要打开 16 进制显示”,接线 TXGND、外置 5V 转 3.3V 供电。客户卡在有接收到,就是不显示——最后定位到串口线不支持这么高波特率。守则:200 万波特率不是所有 USB 转串口线都能跑,日志乱码/无显示先换线;“正常上电,WiFi 是有日志的”——完全无输出要先怀疑接线与线材。守则五无功放应用的播报指示,事件触发加电平CI-1302 不接功放,想用引脚指示有没有人声回复:16 脚(PA)是功放使能,“低电平功放是一直使能的”——静态引脚当不了播报指示。厂商的方法:“在你那些命令后面加一个电平输出的控制作为指示”;自学习过程指示则加自学习的事件触发去指示。守则:专用功能脚的静态电平不代表业务状态,业务指示用业务事件(命令执行/学习流程)挂电平输出实现。附白标小程序的口径公司要自己的小程序(界面/名称换成自己的)——JX-12F 模块可配套白标,手上样机测试好的程序兼容烧录运行。私域品牌化的路径是现成的,选型时确认模块型号支持即可。落地清单开机播报不可延时,时序编排走上电事件分段播报;串口协议发送不可嵌延时,定时器节点触发;旧工程重新生成报错,先查协议字节数,修复三步:改协议→重引用→控制重选;协议WiFi 串口数据上行的通道,设备到小程序的数据走它;WiFi 日志 2000000 波特率,串口线不支持就换线;播报指示用命令后挂电平输出,学习指示用学习事件触发;JX-12F 支持白标小程序,样机程序兼容;平台开发的规则都藏在不能里——每个不能,都有一条替代的能。把替代方案记成守则,开发就顺了。