在蓝牙低功耗（BLE）协议栈中，T_IFS（Inter Frame Space）指的是两个连续的蓝牙数据包之间的最小时间间隔。这个时间间隔对于确保蓝牙设备之间的通信不会相互干扰非常重要。T_IFS 的值设置为150微秒（150us）的原因如下：1. **避

150 µs 的物理账单：T_IFS 与帧间精确计时 本章示例代码：https://github.com/ixbwer/write-BLE-stack-from-scratch/tree/master/02_active_scan 前提知识 阅读本文需要具备以下基础： 理解 BLE 广播与主动扫描流程（1-2 篇和 2-1 篇有详细讲解）：T_IFS 适用于所有有"问答"结构的 BLE 帧间交互——ADV_IND→SCAN_REQ→SCAN_RSP 是最直观的场景。理解三包握手才能直观感受"为什么必须在 150 µs 内回包"。 理解 RADIO 状态机（1-1 有详细讲解）：T_IFS 的本质是从 RX 切换到 TX（或反向）所需时间的上界。不理解 TXRU / RXRU（Ramp-Up）阶段就无法理解 40 µs 补偿数字的来源。 不需要提前了解 PPI 或 TIMER 外设——T_IFS 的概念本身与具体实现方式无关。具体实现（HW TIFS 和 SW TIFS）在 2-3 篇展开。 一、T_IFS：有"问答"的地方就有这条规则 BLE 的物理层是半双工的——一根天线不能同时发送和接收。当甲刚发完一帧，乙还没开始回应的这段空白时间，就叫做帧间间隔。 你可能会想：帧间间隔越短越好，节省空口时间。BLE 规范的答案是：是的，但不能无限短。存在一张硬件账单需要先付清，这个账单的金额就是 150 µs。 BLE Core Spec（Vol 6, Part B, Section 4.2.1）对这张账单给出了精准定义： 在任何需要"应答"的链路层交互中，回包方必须在上一帧最后一个 bit 结束后，恰好 150 µs ±2 µs 内发出回包的第一个 bit。 这条规则叫做 T_IFS（Inter-Frame Space，帧间间隔），适用于 BLE 链路层所有的应答式交互场景： 扫描器收完 ADV_IND → 150 µs 后发出 SCAN_REQ 第一个 bit 广播者收完 SCAN_REQ → 150 µs 后发出 SCAN_RSP 第一个 bit 连接中主设备发完数据包 → 从设备 150 µs 后发出应答包 连接中从设备发完数据包 → 主设备 150 µs 后发出应答包 "恰好"这两个字很关键。 T_IFS 不是"不超过 150 µs"，而是精确等于 150 µs ±2 µs。太早不行，太晚也不行——接收方是在预设位置开了一扇宽度只有 2 µs 的窗户在等，早了还没开，晚了已经关了。 二、±2 µs：为什么窗口这么窄？ 2 µs 的容忍范围是这样算出来的。 BLE 1M PHY 的空口数据速率是 1 Mbps，意味着每 1 µs 正好传输 1 bit。如果回包的第一个 bit 比预期晚了 3 µs，接收方的同步检测逻辑里就会有 3 个 bit 的错位——前导码（Preamble）的同步窗口就此失效，整包数据无法被正确解码，彻底丢失。 从接收方的角度倒推：它只能把等待窗口开得稍微宽一丁点（各允许 ±1 µs），因为再宽一点，偶发的空口噪声就可能被误认为是合法回包的开头，误判率急剧上升。出于信噪比的权衡，±2 µs（即各自向前向后各 1 µs）是 BLE 规范选定的折中点。 这个容忍范围意味着：回包方的计时精度必须优于 2 µs 的误差。换算成等效采样频率，至少需要 500 kHz 量级的精度——每 2 µs 最多只能差一个 tick。 三、150 µs 是一张硬件账单 150 µs 不是工程师拍脑袋定的。从收到上一帧的最后一个 bit，到发出回帧的第一个 bit，芯片内部有一系列硬件阶段必须依次完成。下面的分解展示的是各阶段的最大耗时预算，而非实际执行的先后顺序——真实芯片在实现层面会重排和流水线化这些步骤（具体执行时序见 2-3 篇）。