3、工具链入门：常用联调工具介绍（串口助手、网络调试助手、逻辑分析仪）
做模组联调，说白了就是跟设备「对话」。你得知道它发了什么，回了什么，中间有没有丢包、乱序、或者干脆死机了。我刚开始带项目那会儿，手边就一把烙铁，一个串口助手，硬是调通了一个蓝牙模组的 OTA 升级。嗯，工具不在多，会用才关键。
这一章，我把最常用的三样工具给你捋一遍：串口助手、网络调试助手、逻辑分析仪。它们分别管「有线通信」、「网络通信」和「时序信号」。你想想看，这三样要是玩熟了，市面上八成以上的联调场景你都能应付。
3.1 串口助手：联调界的「瑞士军刀」
串口助手是我用得最多的工具，没有之一。不管是 Wi-Fi 模组、蓝牙模组还是 4G 模组，上电第一件事就是看串口日志。说白了，它就是你的「第二双眼睛」。
3.1.1 核心参数设置
串口通信的参数就那么几个，但错一个就全白搭。我见过有人拿着 115200 的波特率去读 9600 的设备，读了一上午全是乱码，还以为是模组坏了。
| 参数 | 常见值 | 说明 |
|---|---|---|
| 波特率 | 9600 / 115200 / 921600 | 模组出厂默认多为 115200，老设备可能用 9600 |
| 数据位 | 8 | 几乎都是 8 位，极少用 7 位 |
| 停止位 | 1 | 偶尔用 2 位，比如某些工业仪表 |
| 校验位 | None | 大部分模组无校验；有校验时常用 Even |
| 流控 | None | RTS/CTS 在模组联调中很少用 |
3.1.2 HEX 模式 vs ASCII 模式
这个坑我踩过好几次。串口助手一般有两种显示模式：
- ASCII 模式： 显示可打印字符，适合看日志文本。比如模组打印 "AT+OK\r\n"。
- HEX 模式： 显示原始十六进制字节，适合看二进制协议。比如 0x7E 0x03 0x00 0x01 这种。
什么时候用 HEX？我举个例子。有一次调一个 NB-IoT 模组，它上报的数据是二进制编码的温湿度。用 ASCII 看全是乱码，切到 HEX 模式，一眼就看出数据帧结构了。嗯，从那以后我调任何新协议，第一件事就是切 HEX 模式先看原始数据。
3.1.3 常用功能清单
- 定时发送： 模拟周期性心跳包，间隔设 1s~10s 不等。
- 换行符设置： 很多模组 AT 指令需要 \r\n 结尾，少了它模组不响应。
- 日志保存： 联调时一定要开日志文件保存。我曾经调了三天的问题，最后翻日志才发现是某次异常复位导致的。
- DTR/RTS 控制： 有些模组需要拉低 DTR 才能进入烧录模式，串口助手可以直接控制。
3.2 网络调试助手：TCP/UDP 联调的必备搭档
模组联网之后，串口就管不了网络层的事了。这时候你需要网络调试助手。它本质上是一个「虚拟的服务器或客户端」，帮你跟模组建立 TCP 或 UDP 连接。
3.2.1 两种工作模式
| 模式 | 适用场景 | 典型用法 |
|---|---|---|
| TCP Server | 模组作为客户端主动连接 | 模组连上你的 PC，你发指令、收数据 |
| TCP Client | 模组作为服务器等待连接 | 你主动连模组，常用于远程调试 |
| UDP | 无连接通信，丢包不重传 | DNS 查询、NTP 校时、视频流 |
我个人习惯是：优先用 TCP Server 模式。为什么？因为模组上电后主动连你，你不需要知道模组的 IP 地址。尤其是在局域网里，模组 DHCP 拿到的 IP 经常变，你作为 Server 等着它来连，省事很多。
3.2.2 数据收发与抓包
网络调试助手最基本的功能就是收发数据。但这里有个容易被忽略的点：发送新行。很多网络协议也是以 \r\n 或 \n 作为消息结束符的。如果你发的数据后面没带换行，模组可能一直等在那里，以为数据还没发完。
我记得有一次调一个 MQTT 模组，发 CONNECT 报文后模组一直没回 CONNACK。折腾了两小时，最后发现是网络助手默认没勾选「发送新行」，报文长度算对了但结尾没换行，模组协议栈直接丢弃了。从那以后，我每次发数据前都会看一眼换行符设置。
3.2.3 高级技巧：数据回显与流量统计
- 数据回显： 有些网络助手支持「自动回复」功能。你可以预设一条回复规则，比如收到 "PING" 就自动回复 "PONG"。这在测试心跳机制时特别好用。
- 流量统计： 看发送/接收字节数。如果模组发了 100 个字节，你只收到 80 个，那就要查 MTU 分片或者丢包问题了。
- Hex 显示： 跟串口助手一样，网络层也建议先切 HEX 模式看原始报文。TCP 是流协议，没有帧边界，HEX 模式能帮你找到报文边界。
3.3 逻辑分析仪：看「信号」而不是看「数据」
串口助手和网络助手看的都是「数据内容」，但有时候问题出在「信号层面」。比如：
- 模组的 TX 引脚根本没波形
- SPI 时钟频率不对，导致从设备采样错误
- I2C 地址发送后没收到 ACK
这时候就得请出逻辑分析仪了。它不贵，几十块钱的 USB 逻辑分析仪就能干大部分活。
3.3.1 什么时候该用逻辑分析仪？
| 现象 | 可能原因 | 逻辑分析仪能做什么 |
|---|---|---|
| 串口完全没输出 | TX 引脚没配置、电平不对 | 看 TX 引脚有没有电平跳变 |
| 数据偶尔错位 | 波特率偏差、时钟抖动 | 测量实际波特率，看每个 bit 宽度 |
| I2C 设备不响应 | 地址错误、总线被拉死 | 抓 SCL/SDA 波形，看 ACK/NACK |
| SPI 通信失败 | 极性/相位不匹配 | 看 CPOL/CPHA 是否跟从设备一致 |
3.3.2 采样率怎么选？
逻辑分析仪的采样率决定了它能捕捉多快的信号。一个简单的经验法则：采样率至少是信号频率的 4 倍。
- 串口 115200 bps：信号频率约 115 kHz，采样率 1 MHz 就够
- SPI 10 MHz：信号频率 10 MHz，采样率至少 40 MHz
- I2C 400 kHz：采样率 2 MHz 足够
我手头常备一个 24 MHz 采样率的逻辑分析仪，能覆盖大部分模组联调场景。如果遇到高速 SPI 或并行总线，就得用 100 MHz 以上的设备了。
3.3.3 协议解码：把波形变成你能看懂的东西
逻辑分析仪最强大的功能就是协议解码。你抓到的原始波形是一堆方波，但解码之后，它会直接显示：
- UART：0x41 'A' 0x54 'T' ...
- I2C：START + 0x50 (写) + ACK + 0x00 + ACK + STOP
- SPI：CS 拉低 → 发送 0xAA → 接收 0x55 → CS 拉高
我记得有一次调一个温湿度传感器，I2C 读出来的数据总是 0xFF。用逻辑分析仪一抓，发现传感器在第 9 个时钟周期没有拉低 SDA 线 —— 它根本没发 ACK。查手册才发现传感器地址是 0x51，我代码里写的是 0x50。嗯，这种问题看代码看一天都看不出来，看波形 5 分钟就破案了。
3.4 三把工具的配合使用
实际项目中，这三把工具经常要组合使用。我给你画个典型的联调流程：
- 上电第一步： 串口助手看模组启动日志。确认模组正常启动，AT 指令有响应。
- 联网测试： 网络调试助手开 TCP Server，模组连上来。发几条数据，看收发是否正常。
- 异常排查： 如果串口有数据但网络收不到，或者网络有数据但串口没显示，用逻辑分析仪抓模组和主控之间的通信波形。
- 定位根因： 逻辑分析仪抓到波形后，用协议解码功能确认数据内容是否跟串口助手显示的一致。
说白了，串口助手管「内容对不对」，网络助手管「网络通不通」，逻辑分析仪管「信号好不好」。三样东西互相印证，问题基本藏不住。