第一次把 S2-LP 这颗 Sub-1GHz 收发器用进量产项目的时候，我特意把 ST 的 LAT1224 应用笔记翻出来仔细读了一遍，其他内容倒是很快理解，就是 FIFO 机制这块，前前后后花了不少时间才理清楚。S2-LP 的 FIFO 模块看着简单，实际用的时候牵扯到阈值配置、中断标志、溢出处理、SPI 读写节奏，稍不注意就会在收发端出现数据错位或者丢包。这篇文章就围绕 S2-LP 的 FIFO 机制做一次完整梳理，从硬件结构讲到寄存器配置，再结合我在实际调试中踩过的坑，尽量用大白话把这块讲明白，给正准备上手 S2-LP 的朋友一个跳跃式的参考。
S2-LP 是意法半导体推出的一款超低功耗 Sub-1GHz 收发器，支持 433MHz、868MHz、920MHz 等频段，数据速率最高能到 500kbps。它内部集成了一对独立的 256 字节 FIFO，一个用于发送，一个用于接收，MCU 通过 SPI 接口往这两个 FIFO 里写数据和读数据。看起来只是一个简单的缓存区，但它决定了整个无线链路的数据流控制方式，也直接影响丢包率和实时性。
1. 内容和整体设计思路拆解
1.1 FIFO 机制到底解决了什么问题
很多人刚接触 S2-LP 的时候会有一个疑问：射频收发芯片内部明明有数据寄存器，为什么还要单独搞一个 FIFO 出来？这个问题的答案要从无线通信的数据特点来理解。
Sub-1GHz 通信的数据包通常在几字节到一两百字节之间，数据速率不高，但射频前端工作在固定的时序节奏上。发送的时候，基带调制器需要按位从某个地方取数据，然后调制发射出去；接收的时候，解调器把收到的比特流正确还原出来，也需要一个地方暂存，等 MCU 来取。如果 MCU 每次只写一个字节进寄存器，发送过程中就要频繁打断主程序来处理中断，效率非常低，而且一旦时序没配合好，数据流就会出现空隙。
FIFO 就是在这中间加的一层缓冲，MCU 可以把整个数据包一次性写进 FIFO，然后启动发送，之后射频前端会自己按节奏从 FIFO 里取数据，直到发送完成。接收方向也一样，射频前端把收到的完整数据包放满 FIFO，MCU 在空闲的时候一次性读回来，这充分利用了 SPI 的突发传输能力，把 MCU 从实时性极高的 Bit 级时序中解放出来。
这个思路和大多数设计良好的外设类似，比如 UART 的 FIFO、DMA 的环形缓冲。本质上就是用空间换时间，用一块连续的存储区去弥补两个模块在速度上的不匹配。S2-LP 选择 256 字节这个容量，基本上能覆盖常用的最大数据包长度，又不至于在芯片内部占用过多面积和功耗。
1.2 FIFO 模式和直接模式的取舍
S2-LP 除了 FIFO 模式之外，还支持直接模式，也就是 Direct Mode。在直接模式下，数据不经过 FIFO，而是通过 GPIO 引脚直接输入输出到基带调制器/解调器，MCU 需要按位或按字节实时喂数据。这种模式适合什么场景呢？比如你要连续发送一段很长的数据流，超过 256 字节，又不希望分段处理，直接模式就有优势。
但在大多数物联网传感、表计、智能家居控制这些场景下，数据都是离散的数据包，最长也就是一两百字节，FIFO 模式更为合适。FIFO 模式的好处很明确：
- MCU 不参与 bit 级时序控制，释放了大量 CPU 资源
- 支持突发写/突发读，SPI 效率高
- 硬件自动处理字节到比特流的转换，稳定可靠
- 有阈值中断机制，可以高效判断发送/接收进度
我个人的建议是，新项目优先用 FIFO 模式，除非你有特殊需求必须处理长数据流，或者是速率要求高到 FIFO 已经跟不上的程度，否则不需要碰直接模式。直接模式对 GPIO 时序要求非常苛刻，MCU 稍微慢一点就可能出错，调试起来非常痛苦。
1.3 FIFO 在数据包收发链路中的位置
拿整个数据链路来说，FIFO 处在 MCU 和基带处理器之间。发送方向：MCU -> SPI -> TX FIFO -> 基带调制器 -> 射频前端；接收方向：射频前端 -> 解调器 -> RX FIFO -> SPI -> MCU。FIFO 在中间起到了很好的解耦作用，射频链路和 MCU 之间不再互相拖累。
无论发送还是接收，S2-LP 的数据包格式由前导码、同步字、可选的头字节、数据负载、CRC 校验等组成。而 FIFO 里存的只是数据负载部分，前导码、同步字、CRC 都是硬件自动加上的。所以 MCU 写入 FIFO 的内容一般就是协议层的数据单元，这和我们用其他射频芯片的习惯是一样的。
2. 核心细节解析与实操要点
2.1 FIFO 容量与环形缓冲区的工作机制
S2-LP 的 TX FIFO 和 RX FIFO 都是 256 字节，这一点在数据手册里有明确标注。内部实现是一个标准的环形缓冲区，有读指针和写指针。写入时，写指针递增；读取时，读指针递增；当指针到达缓冲区尾部时，会自动回到头部，这就是“环形”的含义。
实际使用中，这个环形结构对用户是透明的。MCU 不需要关心内部指针怎么转，只需要知道当前 FIFO 里有多少数据、剩余空间是多少，以及什么情况下会触发中断。S2-LP 用两个寄存器来帮助 MCU 掌握这些信息，分别对应几乎满（Almost Full）和几乎空（Almost Empty）两个水位线。
这两个阈值的设计其实非常巧妙。我不需要知道 FIFO 精确的使用量，只要知道“已经到高水位了，该读数据了”或者“已经到低水位了，该补数据了”，就能保证数据流不中断、不溢出。这和水库水位的监测逻辑是一样的，你不关心今天到底存了多少立方米水，你只关心是不是快到警戒线了。
2.2 阈值寄存器配置方法
S2-LP 通过 FIFO_CONFIG 寄存器来配置阈值，具体分为两组：一组管 RX，一组管 TX。以 0x17 地址的 FIFO_CONFIG 寄存器为例，高四位配置 RX 的几乎满阈值，低四位配置 RX 的几乎空阈值；另一个寄存器管理 TX 的类似配置。
阈值的单位是 16 字节。也就是说，如果我给 RX 几乎满阈值写 14，那表示数据量达到 224 字节的时候，几乎满标志就会置位。同样，如果给 TX 几乎空阈值写 2，表示 TX FIFO 剩余数据少于 32 字节时，几乎空标志就会置位。这个单位设置和芯片内部的读写策略有关，16 字节一个刻度对绝大多数场景都已经足够精细。
举一个我实际项目里的例子。我做的数据包最大 128 字节，我把 RX 几乎满阈值设为 7（对应 112 字节），几乎空阈值设为 1（对应 16 字节）。这样做的思路是：当 FIFO 内数据量到了 112 字节，距离 256 字节的满值还有比较大余量，MCU 有充足时间通过 SPI 把所有数据读走，不用等到快满了才紧急处理。而几乎空阈值设成 16 字节，是为了保证 MCU 在读取数据时，FIFO 里至少有一点数据可以读，避免因为 SPI 时序造成的短暂空窗直接触发异常判断。
配置阈值这步，我的经验是不要追求“刚刚好”，要留足余量。尤其是 MCU 主频较低、或者 SPI 时钟频率受限的情况下，阈值留过头反而会频繁触发中断，增加 CPU 负担；留太少又可能来不及处理导致覆盖溢出。
2.3 中断标志和状态寄存器
S2-LP 的 FIFO 相关中断标志包括：
- TX_FIFO_ALMOST_EMPTY：发送 FIFO 数据量低于几乎空阈值
- TX_FIFO_ALMOST_FULL：发送 FIFO 数据量高于几乎满阈值
- RX_FIFO_ALMOST_FULL：接收 FIFO 数据量高于几乎满阈值
- RX_FIFO_ALMOST_EMPTY：接收 FIFO 数据量低于几乎空阈值
- RX_FIFO_FULL：接收 FIFO 已满
- RX_FIFO_OVERRUN：接收 FIFO 溢出，也就是新数据覆盖了未读数据
与这些标志对应的是 IRQ 状态寄存器和 IRQ 屏蔽寄存器。如果你不想让某一个标志触发 GPIO 中断，可以在屏蔽寄存器里把它关掉，只保留需要的那几个。像我这边，实际只开了 RX_FIFO_ALMOST_FULL 和 TX_FIFO_ALMOST_EMPTY 两个中断，就能覆盖绝大部分收发场景。
这里有一个细节新手容易忽略：读取 IRQ 状态寄存器的动作本身会清除部分中断标志位。如果你在中断服务函数里一进来就先把状态寄存器读一遍，那么在处理其他逻辑之前标志就已经被清了，后面想去判断是哪种情况就来不及了。我的做法是：中断服务函数里先把 IRQ 状态寄存器的值保存到一个全局变量，然后基于这个保存的值做分支处理，最后再统一清除，避免标志位被提前冲掉。
3. 实操过程与核心环节实现
3.1 TX 发送路径的完整流程
发送数据包的标准流程看起来很简单，但每一步的执行细节都会影响稳定性。
第一步，配置好数据包格式，包括前导码长度、同步字内容、地址过滤、CRC 类型、数据包长度模式。这些配置写在 PCKCTRL 和 SYNC_CONFIG 等寄存器里，和 FIFO 没有直接关系，但它们决定了硬件会往数据帧里加什么。
第二步，往 TX FIFO 写数据。SPI 写入 TX_FIFO 的地址是固定的，我习惯用 0x6C 这个地址。你可以逐字节写，也可以用突发模式一次写完整个数据包。S2-LP 的 SPI 突发模式支持一次连续传输多个字节，效率比逐字节写高得多，强烈推荐。
第三步，启动发送。写入 TX 命令后，S2-LP 进入 TX 状态，自动从 TX FIFO 取数据，加前导码、同步字和 CRC，然后调制发射。
第四步，等待发送完成。发送过程中，TX FIFO 的数据量逐渐减少，当低于几乎空阈值时，TX_FIFO_ALMOST_EMPTY 中断标志置位。如果数据包小于等于 256 字节，一次写入后不需要再补充数据，这个中断告诉我们发送流程基本接近尾声。发送完成后，芯片会自动回到就绪状态，或者进入你设定的低功耗状态。
下表是我项目中一个典型 64 字节数据包的发送时序记录：
| 时间点 | 操作 | FIFO 状态 | 说明 |
|---|---|---|---|
| T0 | MCU 写入 64 字节 | 64/256 | 通过 SPI 突发写入 |
| T1 | 写入 STX 命令 | 64/256 | 启动发送 |
| T2 | 发送进行中 | 约 40/256 | 硬件持续取数 |
| T3 | 触发 TX 几乎空中断 | 16/256 | 低水位中断标志置位 |
| T4 | 发送结束 | 0/256 | 自动回到 READY 状态 |
如果是发送一个大负载，比如 300 字节的数据，一次写不满 TX FIFO。这时候要分批写入。我的做法是：第一次先把前 256 字节写入 FIFO，启动发送后，当 TX 几乎空中断触发时，再写入剩余 44 字节。这里要注意写入节奏，如果两次写入之间的间隔太长，FIFO 空了，发送链路会处于等待状态，实际空中帧的时间间隔会被拉长，接收端如果对这个敏感，就可能判为帧格式错误。所以大负载发送方案里，一定要确保中断响应足够快，SPI 写入足够快。
3.2 RX 接收路径的完整流程
接收方向的流程也一样关键。S2-LP 进入 RX 状态后，射频前端持续监听，检测到有效前导码和同步字后开始接收数据，收到的数据依次写入 RX FIFO。
MCU 的响应策略通常有两种。一种是中断驱动：监听 RX_FIFO_ALMOST_FULL 中断，当数据量达到阈值时，进入中断服务函数读取 FIFO。另一种是轮询：主循环里定时检查 RX FIFO 状态，有数据就读取。工程上第一种更省电，适合电池供电的无线传感节点；第二种逻辑简单，适合主循环本来就很轻量的场景。
读取 RX FIFO 时有两个关键点：
- RX_FIFO 读地址是固定的，我这边用 0x6D。读取操作可以是字节读或者 4 字节突发读，实测下来 4 字节突发读的效率提升很明显，尤其在数据量大的时候。
- 读取完 FIFO 数据后，要通过写命令清除 FIFO 相应区域。这里具体是自动清除还是需要手动清除，取决于你的芯片版本和固件库实现。ST 的驱动例程里通常会在读完 FIFO 后执行一个 FIFO 清空操作，这个动作是确保下次接收链路不会因为残留数据而出错的关键。
关于 FIFO 满溢出的问题，我在测试中遇到过几次。场景是这样的：一次空中传输的数据包特别大，而 MCU 此时正在处理一个优先级更高的任务，没有及时进入中断读取 FIFO。当数据量超过 256 字节时，RX FIFO 溢出，后续数据会把前面没读走的数据覆盖掉。结果就是读回来的数据包头部错乱，CRC 过不了。
解决这一类问题有两个方向。第一，硬件上把 RX FIFO 的几乎满阈值调低，比如 14，对应 224 字节，这样中断触发得更早，留给 MCU 的响应时间更多。第二，软件上在系统调度里给无线接收中断高优先级。如果 MCU 恰好被长任务阻塞了，可以配合 DMA 来读取 FIFO，DMA 需要 CPU 干预的次数很少，能大幅度降低掉数据的概率。
3.3 SPI 访问 FIFO 的三种方式对比
SPI 访问 FIFO 的方式，我总结下来有三种，各有优缺点。
逐字节读写：每次 SPI 传输一个字节，地址自动增加或者手动指定。优点是逻辑简单，适合调试阶段；缺点是效率低，读 256 字节要发起 256 次 SPI 事务，每次都有 CS 拉高拉低的开销。
4 字节突发读写：每次 SPI 传输 4 字节，地址由内部自动计数。这个模式是 S2-LP 特别提供的，效率介于逐字节和长突发之间。它的优势在于，一次 SPI 事务能读回 4 个字节，用的时间大约是逐字节传输的四分之一。我在实际应用中就是用这个模式，配合一个 128 字节的数据缓冲，一个数据包读下来要执行 32 次 4 字节突发读取，整体延迟完全可接受。
长突发读写：一次性传输不可变长度的数据，效率最高。对于 256 字节的 FIFO，一次长突发就能全读出来。但长突发对 SPI 时序稳定性要求高，如果 SPI 时钟比较快而线缆质量不好，可能偶尔出现位错误。实测下来，我的板子上 4 字节突发模式在 1MHz SPI 时钟下非常稳定，所以保险起见我就定了这个方案。
3.4 FIFO 与低功耗模式的交互
S2-LP 本身定位是超低功耗，所以 MCU 的休眠策略和 FIFO 的交互一定要设计好。很多初学者忽略了一个点：S2-LP 进入 SLEEP 或 STANDBY 模式后，FIFO 里的数据是会丢失的，还是保持的？
S2-LP 的 FIFO 内容在 STANDBY 模式下保持，但在 SLEEP 模式下不保证。所以如果你的系统需要休眠且希望保留 FIFO 数据，选 STANDBY 而不是 SLEEP。如果不在乎 FIFO 里的数据，比如接收完一包就进入深度睡眠，那就不用关心这个问题。
另外要注意，S2-LP 进入睡眠状态之后，SPI 接口是否仍然可用，这是取决于具体状态的。我曾经在一个项目中发现，芯片进入 STOP 状态后，我尝试通过 SPI 读 FIFO 状态寄存器，结果读回来的全是 0xFF，一度以为是芯片挂了。后来查了手册才知道，在那些状态下读写 SPI 是不被支持的，需要先唤醒芯片。这个坑可以让很多人排查半天，我在这里先提个醒。
4. 常见问题与排查技巧实录
4.1 发送方向的问题
问题一：发送完成后 FIFO 标志没清干净，导致下次发送异常。
这个现象很典型。我当时的场景是，发送完一包数据后，立刻开始发下一包，结果第二包发送出去的内容和第一包重叠了。排查发现，TX_FIFO_ALMOST_EMPTY 中断标志在第一次发送结束后还是置位的，写入新数据之前没清。解决办法是在每次启动发送之前，先手动清除相应的中断标志位。
问题二：发送大负载时，中间补充数据不及时。
大负载发送时，如果 MCU 响应中断太慢，TX FIFO 会先变空，发射机就会空等，直到新数据写入。这样虽然不会损坏数据，但会导致射频帧的时间不连续。无线协议栈如果采用的是严格的时间片设计，这种时间抖动通常是不可接受的。这个问题要靠优先级调整和中断服务函数精简来解决。
问题三：SPI 写入 FIFO 时地址错误。
S2-LP 的 FIFO 地址和寄存器地址在 SPI 帧里有各自的地址编码。如果忘记把地址高位设置为 FIFO 访问模式，写进去的数据不会进入 FIFO，而是写到了某个寄存器上。我踩过一次这个坑，当时是想往 FIFO 写数据，结果把 PCKCTRL 寄存器改乱了，发射出来一堆乱帧。现在我的做法是定义两个带语义的宏，一个叫 FIFO_TX_ADDR，一个叫 FIFO_RX_ADDR，写代码时绝不直接写裸地址。
4.2 接收方向的问题
问题一：RX FIFO 溢出导致整包 CRC 失败。
这是接收方向最常见的坑。数据到达的速率是不可控的，一旦 MCU 没有及时把 FIFO 读空，新数据就会覆盖未读的数据。排查方法是通过读取状态寄存器看 RX_FIFO_OVERRUN 标志是否置位。看到这个标志，基本就能确定问题是溢出，而不是 CRC 配置错误。
问题二：读取 RX FIFO 后残留数据，导致下一包解析错位。
如果读取 FIFO 之后没有正常清除读指针，下一次接收新数据时可能从旧位置开始读，导致解析出来的数据包里混着上一包的残留。典型的解决方案是在接收处理完成后，执行一次 FIFO 清空操作。但这个清空操作不是对所有版本都通用的，具体看芯片资料。
问题三：阈值的配置对单包和连续包的影响不同。
连续接收模式下，如果 RX 几乎满阈值设置得太低，中断会频繁触发，MCU 负载增加；但如果设置得太高，中断响应不够及时，溢出风险增加。如果你需要跨不同产品配置复用代码，最好把阈值放到配置结构体里，根据不同 RF 速率和数据包长度动态计算，不要硬编码。
4.3 排查技巧速查表
| 现象 | 可能原因 | 排查手段 |
|---|---|---|
| 发送数据包内容错误 | SPI 写入了错误地址 | 检查 SPI 地址，确认是 FIFO 地址而非寄存器地址 |
| 发送大负载停顿 | 补充数据不及时 | 查看 TX 几乎空中断响应时间，调整中断优先级 |
| 接收数据包 CRC 失败 | RX FIFO 溢出 | 查看 RX_FIFO_OVERRUN 标志，降低几乎满阈值 |
| 接收数据错位 | FIFO 残留数据 | 读取后清理 FIFO，确认读指针状态 |
| 低功耗后无法读到 FIFO | 芯片处于深度睡眠状态 | 唤醒芯片后再访问 SPI 和 FIFO |
| 中断被反复触发 | 标志没清除 | 在中断服务函数结束后手动清除对应标志 |
5. 一些实际使用上的补充经验
5.1 驱动代码的分层设计
写 S2-LP 驱动时，我建议把 FIFO 相关操作单独拆成一模块，不要和射频配置混在一起。FIFO 模块提供几个接口：fifo_write_tx、fifo_read_rx、fifo_clear_rx、fifo_set_threshold、fifo_get_status。上层协议栈只调用这几个接口，不关心寄存器的具体地址和位定义。这样代码更清晰，也方便在不同项目之间复用。
硬件抽象层的 SPI 部分也要花点心思。S2-LP 的 SPI 接口对时钟极性的要求比较固定，对应的是 SPI Mode 0，也就是 CPOL=0、CPHA=0。这个配置不复杂，但如果你在调试时发现读回来全是 0xFF，也可以先检查一下 SPI 模式是不是配置对了。
5.2 中断服务函数的编写注意点
在中断服务函数里，我会先把所有需要处理的数据保存到 SRAM 缓冲区，然后设置一个事件标志，主循环再根据标志做完整的协议处理。不要在中断里做耗时操作，比如协议解码、打印日志。S2-LP 的 FIFO 中断要求快速响应，快速读走数据，尽量在几十微秒内完成 SPI 突发读取。
另外，S2-LP 的 IRQ 引脚可以配置成高电平有效还是低电平有效，这个要根据 MCU 的 EXTI 触发边沿来设置。如果两边配置不一致，中断收不到，FIFO 满了也没人管，表现就是无线链路完全不通。这个我在一次原型板上吃过亏，后来在初始化代码里加入了 IRQ 极性自检逻辑，才算彻底放心。
5.3 测试工具和验证方法
调试 FIFO 机制时，只靠示波器看 GPIO 波形远远不够。我的验证流程分三步：
- 第一步，用 SPI 抓包工具或者逻辑分析仪观察 SPI 读写时序，确认读写命令、地址、数据都正确。
- 第二步，用 S2-LP 开发板做回环测试，一块板发、一块板收，通过串口把收到的数据上传到 PC，逐字节比对。
- 第三步，做压力测试，快速连续发送 10000 个数据包，看丢包率和 CRC 失败率。如果 FIFO 阈值配置或者中断响应有问题，压力测试阶段一定会暴露出来。
我曾经用这个流程在两天内定位了一个困扰很久的偶发丢包问题，最后的根因是 SPI 时钟速率太高，长突发读取时偶尔出现位错误。把 SPI 时钟从 8MHz 降到 4MHz 后，问题彻底消失。这个事实证明，量产的稳定性不仅仅取决于代码逻辑，还和信号完整性、硬件布线有直接关系。
5.4 后续可以继续深挖的方向
S2-LP 的 FIFO 机制本身是一个数据通路，理解了它之后，再去看数据包格式配置、地址过滤、自动应答、低功耗监听等功能，思路会顺畅很多。比如地址过滤功能会和 FIFO 配合工作，硬件过滤掉非本机地址的数据包，不往 FIFO 里写数据，这能进一步降低 MCU 的唤醒频率。这批内容在 ST 的参考手册中分散在不同章节，建议下一篇针对 S2-LP 的完整数据包流程做一次串联，把 FIFO、SYNC、CRC、地址过滤放在一条链路里整体分析。
如果条件允许，最好在 PCB 调试阶段就把射频性能测试和协议调试分开。因为协议层的偶发抖动，有时候是 FIFO 机制的问题，有时候是射频链路本身的问题。分开测试，可以很清楚地界定问题是在 MAC 层还是 PHY 层。S2-LP 的 FIFO 状态读取非常方便，软件上随手能输出到调试串口，这比拆硬件、放探头要高效得多。
我在实际项目中最大的体会是，FIFO 机制不是孤立的寄存器配置，它和中断系统、SPI 总线、低功耗策略是紧密耦合的。先把 FIFO 的工作原理和配置要点吃透，其他射频模块的上手难度会降一大截。尤其是你在调试过程中遇到偶发问题的时候，与其盲目调功率、改频率，不如先从 FIFO 阈值和中断响应时间入手，往往更快见效。最后再分享一个小经验：遇到任何无法解释的收发异常，先读一遍状态寄存器，把 FIFO 相关标志全部打印出来，十次里有九次能快速锁定方向。
