前两篇把硬件和WiFi网页通路讲完了。这篇讲BLE这边怎么联调，以及两个无线通路实际跑下来的对比和我的一些使用感受。
DA14531跑的是什么固件
DA14531这个PMOD模块出厂烧的是Dialog的CodeLess固件，说白了就是一个BLE转UART的透传桥。MCU通过SCI4给模块发什么ASCII字符串，手机连上之后就能在Characteristic里收到；反过来手机写Characteristic，模块通过UART吐给MCU。
不用自己写BLE协议栈、不用配GATT服务、不用处理连接参数——这些CodeLess全部帮你做好了。MCU这边看到的就是一个"串口"，和DA16200的AT串口本质上是一类东西，只不过一个走WiFi一个走BLE。
模块上电后自动开始广播，广播名就是你在配置工具里设的名字。MCU启动时通过UART发几个AT指令读一下模块的名字和MAC地址，确认连接正常。
Connect怎么连
手机装一个nRF Connect（这个工具做BLE的应该人人都有），打开就能扫到模块。我这里是使用自己的一个BLE分析仪来展示的在电脑端，这样手机就可以空出来拍视频。我这个广播名是默认的Dialog设备名，MAC地址在启动日志里能打出来。
nRF Connect扫描连接
点连接之后，会自动发现服务。CodeLess固件用的是标准UART Service（UUID大概是6e40xxxx...那个），里面两个Characteristic：
RX Characteristic（写）：手机往这里写数据，模块通过UART吐给MCU
TX Characteristic（通知）：MCU通过UART发数据上来，模块通过notify推给手机
第一次连的时候记得点那个"三个向下箭头"打开notify，不然收不到MCU主动上报的数据。
我设计的ASCII协议
因为是透传，协议层我自己定的，走的是最简单的键值对风格。没搞二进制TLV那种紧凑格式，调试的时候眼睛能看懂最重要。
MCU每500ms上报一次状态：
D=25 T=30 A=0 EN=1
四个字段，一眼就明白：D是滤波后的距离，T是当前阈值，A是报警状态（0正常1报警），EN是报警使能。
手机端发命令也很简单：
| 发送内容 | 作用 |
| T=30 | 把阈值设成30cm |
| EN=1 | 打开报警 |
| EN=0 | 关闭报警 |
| ACK | 手动消警 |
| ? | 让MCU立刻上报一次状态 |
命令之间用回车换行或者分号分隔都行，甚至什么都不加——CodeLess固件有个短超时机制，MCU这边等200ms没新字节就认为一行结束了。这个设计在实际用的时候很方便，nRF Connect里直接打T=25点发送就行，不用纠结换行符。
nRF Connect数据收发
可以看到下面RX框里收到D=57 T=30 A=0 EN=1这样的字符串，上面TX框里可以手动输入命令。我在TX框里发T=50，下一次上报的T值就变成50了，说明命令确实被MCU解析并执行了。
两个通路同时跑是什么体验
这个项目最有意思的地方就是WiFi和BLE同时工作，而且它们不是各自为政，而是共享同一个报警状态机。
MCU里alarm_fsm是唯一的"真相源"。不管是WiFi网页改了阈值，还是手机BLE发了T=30，还是触摸TS2消警，最终都改的是同一个状态机。然后：
WiFi通路每100ms把当前状态通过TCP推给网页
BLE通路每500ms把当前状态通过notify推给手机
所以你会看到一个很直观的现象：在手机nRF Connect里发个ACK消警，网页上的红色报警界面马上就消失了；反过来在网页上拖滑条改阈值，BLE上报的T值也跟着变。两条路是完全同步的。
我实际用的时候试了几个场景：
场景一：手靠近障碍物。 距离从50cm慢慢降到25cm，低于30cm阈值，网页立刻变红，BLE上报的A从0变成1，板上LED3亮。手退到35cm以外，三个地方同时恢复正常。整个过程几乎无感延迟。
场景二：网页改阈值。 网页滑条拖到20cm点下发，BLE下次上报T就变成20了。不用在手机上重新设。
场景三：BLE手动消警。 手放在20cm不动（一直在报警区），网页红色界面亮着。BLE发ACK，网页立刻变绿，但手还没拿开。这时候网页保持绿色（手动消警状态），直到手退过23cm（20+3回滞）再伸进来，才会重新报警。
两个通路的实际对比
跑下来感觉，WiFi和BLE各有各的用处：
WiFi通路优势：
数据率高，100ms一次刷新，网页上数字跟手
不依赖手机App，浏览器打开就用，体验好
可以同时多个客户端看——电脑、手机、平板同时开网页都行
界面交互丰富，滑条按钮什么都能做
WiFi通路劣势：
必须有路由器，板子和电脑在同一个局域网
PC上得跑个Python脚本，不是开箱即用
板子要主动连PC的IP，换个网络环境就得改代码重烧
BLE通路优势：
不依赖路由器，手机直连板子，走到哪连到哪
功耗低，DA14531本身就是为低功耗设计的
没有中间网络设备，连接建立快
nRF Connect调试方便，手动发命令测试很直观
BLE通路劣势：
500ms才刷一次，不如网页跟手
需要装nRF Connect这种调试工具，普通用户不会用
一次只能连一个手机
文本协议，界面就一行字，做不了复杂交互
我的判断是：做产品的话BLE应该是主力，因为它不依赖路由器、功耗低、手机直连。WiFi适合做固定安装场景的远程监控，比如仓库里装一个，办公室电脑上实时看。这个项目两个都做了，主要是为了把瑞萨这两个无线模组都摸一遍。
踩过的几个坑
做的过程中踩了一些坑，记下来供后面做的人参考：
HC-SR04供电： 这个模块标称5V，但我手上这个是3.3V兼容版。一开始差点接5V，后来看模块上的稳压芯片才发现是3.3V的。接3.3V完全能用，而且ECHO脚也是3.3V电平，不需要分压电阻，直接接MCU GPIO就行。
UART波特率： DA16200和DA14531都是115200 8N1，这个两个模组一致，省得改配置。RA4M2的SCI外设配置的时候注意时钟分频别算错，不然收回来全是乱码。
TCP下行不可靠： 一开始我以为TCP连接建好了，PC端往连接里写数据MCU一定能收到。实际测下来发现，模块正在处理AT命令的时候，UART缓冲区可能会满，下行包就丢了。所以才加了HTTP拉取兜底这一层。如果对实时性要求不高，HTTP拉取其实也够用，4秒一次命令延迟可以接受。
滤波参数别贪多： 一开始中值窗口设成5、MA窗口设成4，结果手伸进来要等将近1秒才反应过来，太慢了。后来砍到中值3、MA2，再加跳变检测，响应速度才上来。近场报警这个场景，响应速度比绝对精度重要——差个2cm无所谓，但延迟1秒可能就撞上去了。
总结
用瑞萨这套RA4M2 + DA16200 + DA14531做了一个超声波近场双通路监测终端，整体感受：
RA4M2这个MCU本身挺好的，FSP配置工具用熟了之后加外设很快，DWT计时这种小技巧用起来比配置定时器方便
DA16200的AT固件文档稍微有点绕，ESC-S帧格式和URC解析踩了点坑，但跑通之后就很稳定，TCP长连接挂几天没断过
DA14531 CodeLess真的很省心，不用碰BLE协议栈，当串口用就行，适合快速验证想法
双通路共享状态机这个设计是对的，两个入口改同一个状态，天然同步，不会出现"网页说正常手机说报警"这种不一致
代码全部放在工程里了，从驱动到网页前端到PC桥接都有。后面如果要继续做，可以加个蜂鸣器做声音报警，或者把数据存到PC上画个历史曲线图——不过那就是另一个项目了。这里本来想把源代码上传给需要的朋友进行二次开发，但是没有找到上传附件的功能，所以暂时没有上传，等后面建一个公有地址来上传。
关于视频嵌入这块，我也折腾了半天。本来想把整个演示视频直接嵌在帖子里，结果平台要求3分钟以内的视频才能直接发，我这个录了6分半，超了。想发长视频得下载APP实名认证，但认证又要求先发一条视频才能解锁——等于卡了个死循环。最后没办法，只能把视频传到其他地方放外链，想看完整演示的点链接跳转过去就行。视频链接：https://www.bilibili.com/video/BV1JKa86YEdK/
审核编辑 黄宇