第3章 支持的协议类型总览
协议分析仪到底能看什么？
这是我们拿到设备后第一个要搞清楚的问题。做嵌入式调试这么多年，我见过不少人花大价钱买了分析仪，结果发现不支持手里的协议——那叫一个难受。
这一章，我把常见的协议分成几大类，咱们一个一个过。你不用全记住，但得知道「这东西能搞定什么、搞不定什么」。
3.1 核心协议范围
协议分析仪支持的核心协议大致分四类。我用个表格给你看，一目了然。
| 类别 | 典型协议 | 典型速率 | 常见场景 |
|---|---|---|---|
| 低速串行 | I²C, SPI, UART, SMBus | 10 kHz – 几 MHz | 传感器、MCU外设、PMBus |
| 高速串行 | USB 2.0/3.0, PCIe, Ethernet | 百 MHz – 几十 GHz | PC外设、存储、网络设备 |
| 汽车与工业 | CAN, LIN, FlexRay, Profibus | 1 Mbps – 10 Mbps | 车载网络、PLC、电机控制 |
| 射频与无线 | I²S, Bluetooth HCI, SPI‑RF | 取决于基带 | 音频编解码、无线模块调试 |
我的习惯：每次开始一个新项目，第一件事就是把目标协议的物理层参数查清楚。你想想看，如果电平标准是1.8V，你拿着3.3V阈值直接往上怼，解码出来的全是乱码——这坑我以前跳过。
3.2 低速串行协议详解
这一块是日常调试的「重头戏」。做嵌入式开发的人，基本天天跟它们打交道。
3.2.1 I²C / SMBus
I²C的特点是两根线：SCL和SDA。它用地址寻址，支持多主设备。我个人习惯在调试I²C时，先看起始条件和停止条件是否干净。很多丢包问题，其实都是SCL上的毛刺引起的。
SMBus是I²C的衍生品，多了一个超时机制。我记得在帮客户定位一个PMBus电源管理模块时，对方说「写寄存器成功了，读出来不对」。后来抓到波形才发现——SMBus要求的时钟低超时没满足，总线被锁死了。
3.2.2 SPI
SPI比I²C更简单，四根线：SCK、MOSI、MISO、CS。没有地址，靠片选线区分设备。项目中最容易出问题的是什么呢？就是时钟极性和相位没配好。
# 配置SPI的时钟极性和相位
spi_config = {
'clock_polarity': 0, # CPOL=0，空闲低电平
'clock_phase': 1, # CPHA=1，第二个边沿采样
'bit_order': 'MSB_FIRST'
}
# 如果你的从设备用的是CPOL=1 / CPHA=0，这个配置就会全错我曾经踩过一个坑：用SPI读取ADC数据，总是隔几个字节就跳一个值。折腾了两天，最后发现从设备的CPHA和主机配反了。所以，建议你把SPI的时序图先画出来，再填参数。
3.2.3 UART
UART就是一根TX、一根RX。关键是波特率要匹配。举个常见的例子：你设了115200，对方实际是57600，那么收到的东西就会是乱码。不过现在的分析仪大多支持自动波特率检测——这是一个很实用的功能，省了很多手工算的时间。
3.3 高速串行协议
这类协议的调试难度提升了一个档次。为什么呢？因为它们往往有复杂的物理层编码，比如USB的NRZI、PCIe的8b/10b编码。
3.3.1 USB
USB 2.0靠D+和D-两条差分线传信号。解码时你得告诉分析仪是Host还是Device模式。我之前遇到过个奇怪的现象：USB枚举老是失败，但示波器看眼图是正常的。后来发现是D+的上拉电阻虚焊，导致从设备模式没切过去。
3.3.2 PCIe
PCIe更复杂。它有多条Lane，每条Lane都用差分对传。解码的时候，你不仅要抓单Lane的数据，还得把多Lane的数据重组起来。说白了，这是硬件和协议栈的联合调试。
关键点：高速协议的解码，强烈建议配合物理层眼图分析一起看。协议格式再对，物理层烂了也是白搭。
3.4 射频与无线协议
很多人觉得射频协议很难调试，其实只要抓到基带信号，解码思路是一样的。比如蓝牙HCI（主机控制接口），本质上就是UART帧，只是封装了特定格式的命令和事件。
I²S是音频领域最常见的协议。它有三根线：BCLK（位时钟）、LRCLK（左右声道选择）、SDATA（数据）。我帮客户调过一款智能音箱，声音断断续续，最后发现是LRCLK的占空比不对劲，导致左右声道数据混在一起了。
3.5 汽车与工业协议
这类协议的容错要求特别高。因为车上或者工厂里，电磁环境很恶劣。
3.5.1 CAN / CAN FD
CAN是差分信号，两根线CAN_H和CAN_L。它用显性/隐性位表示逻辑0和1。调试CAN时，你要注意总线终端电阻——没有120Ω终端电阻，波形反射会严重到解码全错。我曾经在产线上遇到过一批控制器通信不稳，查到最后是PCB布线时CAN_L的线长没等长，差了2厘米，反射搞死的。
3.5.2 LIN
LIN是单线协议，基于UART加了个从机应答机制。它的速率很低，但结构简单，很适合做车身的门控、车窗调试。
3.6 协议解码与验证方法
搞清楚了协议类型，具体怎么验证解码是否正确？我一般是三步走：
- 抓已知信号：比如用一块开发板，发一段你能预测的数据（比如0x55, 0xAA），看分析仪解码出来后跟预期对不对得上。
- 检查原始波形：工具软件一般会同步显示波形和解码结果。你选中一个解码出的字节，看波形上对应的电平和时序，跟协议规格书对照一下。
- 对比其他工具：如果有逻辑分析仪或示波器，可以同时抓同一段信号。两个工具解码结果一致，基本就能放心了。
一个小技巧：很多协议分析仪支持「协议过滤」功能，你可以在海量数据里只显示特定地址或命令。我个人习惯先开启过滤，缩小范围，再导出结果做分析。省时省力。
3.7 本章知识框架图
为了让你对整个协议结构有个直观印象，我画了一张框架图。它把协议按照「物理层」和「协议层」两个维度组织起来，模拟了数据从接线到解码的流向。
从左边看起：物理层信号进入分析仪，它可以是低速串行、高速串行、汽车工业或射频无线。右边是协议层的处理链路：先校验时序对不对，再从信号里提取出数据，如果有错误会标记出来，最后你可以过滤和导出需要的内容。说白了，整个工具链就是「把物理层的毛刺信号，翻译成你能看懂的协议数据」。
核心总结：协议分析仪的核心能力取决于它对物理层信号的理解。无论协议多复杂，采样率够不够、触发条件对不对、时钟恢复好不好——这几个基础指标直接决定了你能不能解码成功。