蓝牙概览¶
概述¶
本指南介绍如何为 SF32 产品规划和实现蓝牙（Bluetooth）连接，重点说明实际设计中需要权衡的事项：BLE 与双模蓝牙选型、GATT 服务设计、蓝牙应用规范（Profile）选择、连接参数调优、配对与安全、LE Audio，以及蓝牙与图形、音频和传感器工作负载的共存。
SF32 将应用处理与时序要求严格的蓝牙控制器任务分开。应用处理器通常运行产品逻辑和 UI，蓝牙处理器或低功耗处理器负责链路层时序与射频调度。主机（Host）协议栈和 GATT 服务运行在哪个处理器上，取决于芯片和 SDK 配置，不能一概认为都在应用处理器上。应检查所选示例的处理器配置和核间通信方式。
底层子系统的详细说明请参阅蓝牙处理器架构。
规划产品的无线功能时，可用本文梳理所需的角色和 Profile、用户对响应速度与续航的预期，以及手机、无线链路和应用固件之间的职责划分。本文提供设计指导，不能替代在目标手机和配件上进行互操作性验证。
明确产品的连接需求¶
编写任何 GATT 代码之前，应先明确产品的实际需求：
- 仅支持 BLE，还是需要双模蓝牙（经典蓝牙 + BLE）？
- 是否需要蓝牙音频——经典蓝牙（A2DP/AVRCP/HFP）还是 LE Audio？
- 典型连接间隔、延迟（latency）和吞吐量要求是什么？
- 应用处理器需要多频繁地唤醒，又能保持多长时间睡眠？
- 产品需要与手机端现有服务互操作，例如通知、媒体控制和通话，还是只连接自定义配套应用？
- 预期通信距离、天线和外壳限制，以及射频认证目标是什么？
- 固件更新是否通过蓝牙传输？
这些答案会影响器件选型、SDK 示例的选择，以及主 CPU 可保持睡眠的时长。
选择 BLE、经典蓝牙或双模蓝牙¶
低功耗蓝牙（BLE）¶
对于多数联网可穿戴设备和传感器，BLE 是合理的默认选择：流量间歇且由事件驱动、平均功耗低，并受到主流手机操作系统广泛支持。以 BLE 为主的典型产品包括运动手环、健康传感器、信标，以及连接配套应用的配置或控制链路。
经典蓝牙与双模蓝牙¶
产品需要音频流（A2DP/AVRCP）、免提通话（HFP）、串口式数据链路（SPP），或兼容现有经典蓝牙 Profile 时，应加入经典蓝牙支持。双模设计对射频调度和共存的要求高于仅 BLE 设计，而专用蓝牙处理器正是为了将这类负载与系统其他部分隔离。
并非所有 SF32 系列都提供双模蓝牙。确定具体型号之前，请查看蓝牙处理器架构中的器件对比表。
选择合适的 SF32 器件¶
应根据产品所需连接功能选择器件，而不能只看时钟频率。
| 需求 | 选型参考 |
|---|---|
| 仅 BLE 的可穿戴设备或传感器 | SF32LB55x |
| 成本优化的双模蓝牙产品，例如音频配件或模组 | SF32LB52x |
| 具有更丰富显示或 UI 的双模蓝牙产品 | SF32LB56x |
| 需要双模蓝牙，并用两个应用处理器分担图形和本地音频处理 | SF32LB57x |
| 同时需要蓝牙、图形、AI 和大容量内存的旗舰产品 | SF32LB58x |
| 低功耗内核只需用作蓝牙控制器 | SF32LB52x |
| 低功耗内核还需运行额外的用户可编程常开任务 | SF32LB55x / SF32LB56x / SF32LB58x |
如果产品不仅需要连接功能，还需要显示、较大内存或 AI，应结合图形概览和 AI 加速器页面交叉评估。
GATT 服务与 Sibles 框架¶
SiFli-SDK 通过 Sibles 注册和使用 GATT 服务。GATT 定义服务与特征的层级结构及属性访问方式；GAP 负责设备发现、广播、连接建立及相关角色。二者职责互补，不能理解为 GATT 构建在 GAP 之上。开发时应优先参考最接近需求的 SDK 示例，而不是从零构建 GATT 数据库。
SDK 提供多种标准和厂商 Profile 的示例实现，包括：
| Profile / 服务 | 典型用途 |
|---|---|
| HRPC（心率采集端 Profile） | 作为 GATT 客户端接收外部心率传感器的测量数据，适用于运动和健康监测产品。 |
| DISS（设备信息服务） | 向手机提供制造商、型号和固件版本。 |
| CTS（当前时间服务） | 将手机时间同步到设备。 |
| BASC / CSCPC / CPPC | 面向运动场景的电池、骑行速度与踏频、骑行功率客户端 Profile。 |
| HID over GATT | 模拟键盘、遥控器及其他输入设备。 |
| ANCS（Apple Notification Center Service）客户端 | 在设备上读取 iOS 通知。 |
| AMS（Apple Media Service）客户端 | 从设备控制 iOS 媒体播放。 |
| 串行传输 Profile | 通过 BLE 实现自定义双向数据传输，概念上类似 SPP，但建立在 GATT 之上。 |
可复用最接近需求的示例中的注册流程、事件处理和安全检查。实现标准 Profile 时，应保留标准 UUID 和规定行为；产品数据模型确有需要时，可以设计自定义服务和 UUID。重点是复用经过验证的基础代码，而不是把所有手机 App 协议都硬套进某个标准 Profile。
经典蓝牙 Profile¶
对于双模产品，SDK 提供以下 Profile 示例：
- SPP——简单的双向串行数据，适合旧式或不使用 GATT 的配套应用。
- A2DP（Sink 和 Source）——蓝牙音频流。
- AVRCP——配合 A2DP 链路实现播放控制，包括播放、暂停、曲目和音量。
- HFP——免提通话，包含免提设备（HF）和音频网关（AG）两种角色。文档中的 HFP 示例 实现 HF；所选 SDK 配置是否支持 AG，需单独确认。
- PAN——蓝牙网络，包括通过 PAN 传输 OTA 固件的示例。
与普通 BLE 链路相比，音频和传统 Profile 通常具有更严格的时序和吞吐量要求，因此应为共存测试预留足够时间，详见下文与其他工作负载共存。
蓝牙音频与 LE Audio¶
根据音频方案不同，有两条独立路径：
- 经典蓝牙音频——A2DP 用于音频流、AVRCP 用于播放控制、HFP 用于通话。技术成熟，并与现有手机和耳机广泛兼容。
- LE Audio——基础音频应用规范（Basic Audio Profile，BAP）定义了管理单播和广播 LE Audio 音频流的流程。SDK 提供广播发送端（Source）和广播接收端（Sink）示例，也提供 LE Audio 广播发送端与经典蓝牙混合工作的示例，适用于过渡期需要兼容两类方案的产品。
两条路径都需要稳定的时序、缓冲和音频采样数据的可靠传输，通常使用 DMA。当 SF32LB52x/56x/58x 所支持的蓝牙音频角色和 SDK 配置满足产品要求时，可选用它们。SF32LB55x 仅支持 BLE，不能提供经典蓝牙音频，但这并不意味着它没有本地音频能力。DMA 和缓冲区设计请参阅音频概览及蓝牙处理器架构。
Sibles 服务实现模式¶
易于维护的 BLE 服务通常遵循以下模式：
| 步骤 | 固件职责 | 评审重点 |
|---|---|---|
| 定义服务接口 | UUID、特征、权限和通知行为。 | 与配套应用和安全要求保持一致。 |
| 注册服务 | 沿用最接近的 SDK 示例所用的 Sibles/GATT 框架路径。 | 避免为单个服务另行搭建注册流程。 |
| 有目的地广播 | 只包含发现和重连所需的数据。 | 广播载荷应小而稳定。 |
| 限制写入 | 验证长度、状态、权限和命令顺序。 | 防止异常应用流量破坏固件稳定性。 |
| 节制发送通知 | 只发送变化或批量数据，不重复发送相同状态。 | 节省空口时间和空闲功耗。 |
| 保存状态 | 安全保存绑定密钥和产品设置。分别维护每个客户端的 CCCD 订阅状态：已绑定客户端的状态应跨连接保留，未绑定客户端每次连接时应恢复默认值。 | 验证重启和 OTA 后的恢复流程；应处理 GATT 数据库变更，不能直接恢复旧句柄。 |
该模式有助于让服务定义、手机 App 接口、安全策略和功耗行为保持一致。
广播与连接参数¶
连接和广播参数是权衡延迟、吞吐量与功耗的主要手段。
这些连接参数针对 BLE ACL 链路，并非适用于所有蓝牙音频传输。经典蓝牙音频使用 BR/EDR 传输时序，LE Audio 使用 CIS 或 BIS 等时传输时序，不能直接用 BLE GATT 连接间隔设置这两类音频链路。相关传输方式的区别可参阅蓝牙 SIG 的 LE 入门说明。
| 参数 | 影响 | 建议 |
|---|---|---|
| 广播间隔 | 发现速度与广播功耗 | 在限定的快速发现窗口内采用较短间隔，随后在等待连接或重连时延长间隔。已经建立连接，并不意味着必须继续广播。 |
| 连接间隔 | BLE ACL 响应时间与功耗 | 对低流量链路，较长间隔可降低平均功耗；较短间隔可改善交互响应。应在目标手机上验证协商后的参数、吞吐量和电流。 |
| 外设延迟（旧版 SDK 中称为 Slave Latency） | 允许外设跳过连接事件 | 对多数时间空闲的链路可延长续航；低延迟优先时设为 0。 |
| 监督超时 | 连续未收到有效链路层数据包时，判定连接丢失前允许的最长时间 | 过短会导致边缘射频环境下掉线；过长会延迟真实断线后的重连。 |
| TX 功率 | 通信距离、功耗与共存 | 从满足通信距离要求的最低档位开始，实测整机能耗、重传和最终外壳中的共存表现。如果低功率导致频繁重传，最低档位未必最省电。 |
信标类产品（兼容 iBeacon 广播）和周期广播应用，包括用于大规模或单向广播的周期广播同步，都有专用 SDK 示例支持，无需建立完整 GATT 连接。
连接间隔、外设延迟和监督超时必须组成有效的参数组合，并获得控制器和对端接受。发出参数更新请求不代表设置已经生效：应记录实际协商结果，在目标手机或配件上验证，包括更新被拒绝的情况，以及恢复空闲省电设置的过程。
按产品阶段设置参数预设¶
不同产品阶段应使用不同的蓝牙参数，而不是始终采用一组折中设置：
| 阶段 | 典型目标 | 参数方向 |
|---|---|---|
| 首次发现 | 快速的用户体验 | 较短广播间隔、明确设备身份、限制持续时间。 |
| 重连 | 降低平均功耗 | 超时后延长广播间隔；适用时采用定向或过滤行为。 |
| 交互控制 | 低延迟 | 缩短连接间隔，使用较低或为 0 的外设延迟。 |
| 已连接空闲 | 电池续航 | 延长连接间隔、采用非零外设延迟、尽量减少通知。 |
| BLE OTA 传输 | 吞吐量与可靠性 | 缩短连接间隔、禁用外设延迟、使用保守的监督超时。 |
| 音频 | 稳定时序 | 根据编解码帧时序和缓冲深度选择参数。 |
应记录各阶段之间的切换。许多看似随机的蓝牙功耗或延迟问题，实际原因是状态变化后产品仍停留在错误阶段。
配对、绑定与安全¶
BLE 无需配对也能建立连接。配对用于建立安全密钥，绑定则保存这些密钥，供后续连接使用。应按服务需求确定加密、认证和持久化绑定要求，而不是默认所有产品都必须绑定：
- 尽早确定产品采用 Just Works、配对码输入（Passkey Entry）还是数字比较配对。Just Works 不提供中间人攻击（MITM）防护：链路已加密不等于完成了身份认证。应根据双方的 I/O 能力和产品安全要求选择配对方式，详见蓝牙 GAP 安全要求。
- 对于 ANCS，手机端的用户授权与链路加密、绑定是不同的条件，应处理用户拒绝或撤销授权的情况。ANCS 和 AMS 都可能在连接期间出现或消失。应监测 Service Changed 并重新发现服务，不能认为配对成功后服务就始终可用。
- 按照 SDK 推荐的存储或分区方式保存绑定信息，确保设备重启或 OTA 更新后仍能保留绑定关系。
- 分别为产品 UI 和手机端定义重新配对及“忘记设备”流程。
- 将安全策略，包括加密要求、I/O 能力和密钥长度，作为产品决策，而不能保留未经评审的默认值。
多连接与角色¶
SDK 提供同时承担中心端和外设端角色及多个并发连接的示例。例如，产品可作为 BLE 外设端连接手机，同时作为中心端连接传感器，也可维持多个配套设备连接。应根据所选芯片、控制器固件、SDK 配置、缓冲区和实际无线负载，确认角色组合与连接数量上限；示例能运行不代表整个系列都具备相同的连接容量。
如果产品需要接近链路吞吐量上限，应先以 SDK 吞吐量示例建立基准，再判断限制是否来自应用代码。
通过蓝牙进行 OTA 固件更新¶
常见的固件传输路径有两种：
- 通过 BLE 进行 DFU 式更新，集成在外设端连接中。
peripheral_with_ota示例展示了如何把 OTA 接入普通的外设端 GATT 角色。 - PAN OTA，适用于已经使用 PAN 传输数据的双模产品，通过蓝牙 PAN 网络链路传送固件。
无论采用哪种方式，都应在发布前规划并验证分区布局、故障恢复和回滚机制。BLE OTA 传输时，可评估缩短连接间隔并将外设延迟设为 0，传输结束后恢复正常的省电设置。PAN OTA 使用经典蓝牙传输，应单独调整吞吐量和故障恢复策略，不能直接套用 BLE 连接参数。
与其他工作负载共存¶
SF32 上的蓝牙通常与图形、音频、传感器，有时还包括外部 Wi-Fi 共享系统资源。专用蓝牙处理器可吸收大部分链路时序风险，但应用层仍需关注共存问题：
- 应用处理器上的长临界区或长时间关闭中断，可能延迟 Host 侧蓝牙处理。
- 显示和 PSRAM 流量会与蓝牙音频缓冲区竞争内存带宽。
- 如果传感器中断频繁唤醒应用处理器，可能抵消蓝牙处理器独立处理链路、让应用处理器继续睡眠所带来的省电收益。
系统级说明请参阅与其他工作负载共存。测试应覆盖符合实际情况的最坏组合，例如显示活动、音频播放和繁忙 BLE 链路同时运行，而不能只隔离测试各子系统。
射频、互操作性与认证准备¶
蓝牙固件应采用与射频硬件相同的严谨方式进行验证：
- 使用多个手机品牌、操作系统版本和重连场景测试，不能只使用一部开发手机。
- 检查绑定信息过期、手机端忘记设备、设备端恢复出厂设置和 OTA 后的行为。
- 在最终外壳中安装电池和显示屏，并覆盖充电器连接及用户佩戴或手持姿态，验证通信距离和数据包稳定性。
- 保留射频测试模式、校准接口和日志，以支持生产和认证。
- 对使用多个 Profile 的产品，应为适用性验证（qualification）和 Profile 测试预留时间；演示应用可以运行不等于产品具备互操作性。
蓝牙问题排查¶
| 现象 | 重点检查方向 |
|---|---|
| 发现速度慢或不可靠 | 广播间隔和类型、射频布局、天线匹配。 |
| 射频条件良好时仍频繁断开 | 监督超时过短、连接间隔不匹配、共存干扰。 |
| 连接“空闲”时功耗仍很高 | 未设置外设延迟、应用处理器唤醒过于频繁、存在不必要的 GATT 流量。 |
| 音频异常或断续 | DMA 缓冲区数据耗尽、与显示/PSRAM 访问争用资源，或传输链路的时序和配置存在问题（经典蓝牙音频使用 BR/EDR，LE Audio 使用 CIS/BIS）。 |
| 配对偶发失败 | 绑定信息存储问题、I/O 能力不匹配、一侧仍保存着过期的绑定信息。 |
| 实验台测试时通信距离正常，装入外壳后明显变差 | 外壳、电池或 PCB 导致天线失谐，TX 功率设置，射频匹配网络。 |
常见错误¶
- 产品已经需要经典蓝牙音频，却选择仅支持 BLE 的硬件。
- 重复实现已有的服务基础代码，或把自定义数据模型硬套进不适用的标准 Profile。
- 对绝大部分时间处于空闲状态的链路，仍将外设延迟保持为 0。
- 直到集成后期首次组合显示、音频和蓝牙时，才开始共存测试。
- 把配对和绑定当作附加功能，而不是经过设计的用户体验流程。
- 把射频启动调试与验证拖到最终 PCB 版本才做，包括天线、匹配网络和晶振精度。
- 假定仅靠固件调优就能弥补不良射频布局。
启动调试检查清单¶
- 确认仅 BLE 或双模蓝牙需求，并选择匹配的 SF32 器件。
- 确定最接近产品应用场景的 SDK Profile 或服务示例。
- 分别定义发现、活动使用和空闲状态下的广播与连接参数目标。
- 设计配对、绑定和“忘记设备”的用户体验。
- 在真实硬件上验证射频布局、天线匹配和晶振精度。
- 使用真实手机或参考主机启动调试所选 Profile，包括 GATT 服务、A2DP/AVRCP/HFP 或 LE Audio 广播。
- 在符合真实情况的组合负载下，测试蓝牙与显示、音频和传感器工作负载的共存。
- 如果固件将通过蓝牙更新，规划并测试 OTA 传输路径。
- 分析已连接空闲功耗，并确认应用处理器按预期睡眠。
要点¶
- 首先确定仅 BLE 还是双模蓝牙；该决定会影响器件选型和后续大部分 SDK 开发路径。
- 应从 SDK 现有 GATT 服务和经典蓝牙 Profile 示例开始，包括 HRPC、DISS、CTS、HID、ANCS/AMS、SPP、A2DP、AVRCP、HFP 和 PAN，而不是从零实现。
- 连接间隔、外设延迟、监督超时和 TX 功率，是平衡延迟、吞吐量与功耗的主要手段。
- 开发蓝牙音频产品时，应先确认所选器件和 SDK 配置支持所需的经典蓝牙或 LE Audio 角色，再设计并验证缓冲和共存。系列层面的能力描述不能代替具体型号验证。
- 蓝牙是系统级问题：射频布局、时钟、配对体验，以及与图形、音频和传感器的共存，与 GATT 代码本身同样重要。
如需按工程任务查找当前的经典蓝牙、BLE 和 LE Audio SDK 项目，请参阅蓝牙 SDK 示例。
如需了解如何测量和分析目标设备的蓝牙功耗，请参阅蓝牙功耗测量与分析。
最后更新: