第四章 触发设置的艺术：上升沿、下降沿、电平触发、协议触发
触发设置这东西，说白了就是让逻辑分析仪知道「什么时候该干活」。
我刚开始用逻辑分析仪那会儿，总觉得触发嘛，随便设一个就行。结果呢？抓回来的波形要么是空的，要么是乱七八糟的一大堆，根本找不到想看的东西。后来被项目逼着啃了几天手册，才算真正搞明白——触发设得好，调试效率能翻好几倍。
4.1 上升沿触发与下降沿触发
这是最基础的两种触发方式。逻辑分析仪检测到信号从低变高（上升沿）或者从高变低（下降沿）时，立刻开始采集数据。
什么时候用上升沿？
- 你想看某个信号被拉高之后发生了什么
- 比如MCU的GPIO输出高电平去使能一个外设
- 或者SPI的时钟上升沿采样数据
什么时候用下降沿？
- 你想看某个信号被拉低之后发生了什么
- 比如中断请求信号（IRQ）通常是下降沿有效
- 或者I2C的起始条件就是SCL高电平时SDA下降沿
我在项目中遇到过一个问题：一个传感器模块偶尔不响应主机的读取请求。用上升沿触发抓了主机发送的时钟信号，发现时钟个数是对的，但时序图上有个毛刺把数据移位了。嗯，这就是上升沿触发的典型用法——盯着时钟边沿看数据。
小技巧：如果你不确定该用上升沿还是下降沿，可以先用「任意边沿」触发抓一段波形看看，确认信号的实际行为后再调整。
4.2 电平触发
电平触发不是看边沿，而是看信号的电平状态。比如你设置「当信号A为高电平时触发」，那么只要A保持高电平，分析仪就会一直触发。
你想想看，这玩意儿什么时候有用？
- 调试复位电路时，我想看复位信号被拉低后系统怎么启动的
- 调试电源管理时，我想看某个电压轨达到稳定电平后外设的行为
- 或者检测某个信号是否卡死在某个电平上
我曾经调试一个低功耗产品，设备在休眠模式下偶尔会莫名其妙地唤醒。用下降沿触发抓中断引脚，抓了半天没抓到。后来换成电平触发——设置「当唤醒引脚为高电平时触发」，结果发现是电源噪声导致引脚电平抖动，触发了误唤醒。要是只用边沿触发，这个问题根本抓不住。
注意：电平触发容易触发多次，尤其是信号有抖动的时候。建议配合「触发后延时」或者「触发后重新武装时间」来用，不然你会被海量数据淹死。
4.3 协议触发
协议触发是高级玩法。逻辑分析仪内置了协议解码引擎，你可以直接设置「当I2C总线上出现某个设备地址时触发」或者「当SPI的CS片选信号拉低时触发」。
我个人觉得，协议触发是物联网设备调试中最实用的功能。为什么？因为现在的设备基本都是总线通信，你不可能一根一根信号线去查。
4.3.1 I2C地址触发
举个例子。你的系统里有多个I2C设备：一个温湿度传感器（地址0x44）、一个加速度计（地址0x68）、一个OLED屏幕（地址0x3C）。你想看主机和温湿度传感器之间的通信，怎么办？
用I2C地址触发，设置目标地址为0x44（写方向）或者0x45（读方向）。分析仪会自动过滤掉其他设备的通信，只抓取和这个地址相关的数据包。
// 以Saleae Logic Analyzer为例，设置I2C地址触发
// 1. 添加I2C协议分析器
// 2. 在触发设置中选择"I2C Address"
// 3. 输入目标地址：0x44
// 4. 选择方向：Write（写）或 Read（读）或 Both（双向）
// 5. 点击应用我记得有一次调试一个I2C总线冲突的问题。两个设备地址竟然设置成了相同的0x50，结果主机一发送命令，两个设备同时响应，数据全乱了。用I2C地址触发分别抓取两个设备的通信，发现其中一个设备在地址匹配后没有正确释放SDA线，导致总线被拉死。
4.3.2 SPI片选触发
SPI协议触发通常用片选信号（CS）作为触发条件。当CS从高变低时，表示一次SPI传输开始，分析仪就开始抓数据。
我建议你在调试SPI设备时，一定要用CS触发。因为SPI的时钟和数据线是共享的，如果没有CS触发，你抓到的可能是其他设备的通信数据，根本对不上号。
4.3.3 UART触发
UART触发可以设置起始位、数据内容或者特定的字节序列。比如你想抓设备发送的「AT+OK」响应，就可以设置触发条件为收到「AT」这两个字节。
实战经验：协议触发虽然强大，但别滥用。我见过有人把所有协议触发都打开，结果分析仪一直在触发，根本停不下来。建议一次只设置一个触发条件，调试完一个再换下一个。
4.4 触发设置的实战场景对比
| 触发类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 上升沿触发 | 时钟信号、使能信号、中断请求 | 简单直观，容易定位边沿事件 | 无法区分不同设备的数据 |
| 下降沿触发 | 复位信号、I2C起始条件、低电平有效中断 | 适合检测负脉冲事件 | 同样无法区分数据内容 |
| 电平触发 | 电源状态检测、信号抖动分析、复位时序 | 能捕获持续状态异常 | 容易误触发，需要配合延时 |
| I2C地址触发 | 多设备I2C总线调试、设备地址冲突排查 | 精准过滤，只抓目标设备 | 需要知道设备地址 |
| SPI片选触发 | 多设备SPI总线调试、片选时序验证 | 按传输事务抓取，数据完整 | 需要占用一个通道监测CS |
| UART数据触发 | AT指令调试、特定数据包捕获 | 按内容过滤，精准定位 | 需要知道目标数据内容 |
4.5 触发设置的避坑指南
我曾经踩过几个坑，写出来给大家提个醒。
坑一：触发深度不够
有一次我设置I2C地址触发，抓到了起始条件，但后面的数据因为触发深度不够被截断了。后来才发现，触发深度至少要设置到能覆盖一次完整传输的长度。我现在的习惯是：触发深度设为采样深度的10%-20%，留足余量。
坑二：触发位置选错
逻辑分析仪通常有「触发前」和「触发后」的采样比例设置。如果你设成100%触发后，那触发之前的数据就全丢了。我调试时序问题时，一般设成50%触发前、50%触发后，这样既能看触发前发生了什么，也能看触发后的响应。
坑三：协议触发和边沿触发混用
有些分析仪支持多级触发，比如先检测到I2C地址，再检测到某个数据字节。但混用时要小心优先级和触发条件冲突。我建议新手先单用协议触发，等熟练了再尝试组合触发。
4.6 我的个人工作流
说了这么多，分享一下我现在调试物联网设备时的触发设置流程：
- 先看现象：设备不工作？通信失败？还是偶尔死机？
- 选触发类型：如果是通信问题，直接用协议触发；如果是时序问题，用边沿触发；如果是状态问题，用电平触发。
- 设触发条件：比如I2C地址触发，输入目标地址；或者SPI片选触发，选CS引脚。
- 抓一次看看：先抓一小段波形，确认触发条件设置正确。
- 调整参数：根据第一次抓到的结果，调整采样率、触发深度、触发位置。
- 反复迭代：直到抓到你想看的那段波形为止。
嗯，这套流程看起来简单，但实际用起来很管用。我带的几个新人，按这个流程走一遍，基本都能自己搞定触发设置。
触发设置这东西，说白了就是「让分析仪在正确的时间点开始干活」。设对了，事半功倍；设错了，你就是在浪费时间。下次调试的时候，多花两分钟想想：我到底想看什么？用什么触发最合适？相信我，这两分钟花得值。