蓝牙处理器¶

简介¶

**蓝牙处理器（Bluetooth processor）**是 SF32LB 器件内部专用于无线控制的子系统，负责蓝牙运行中对时序敏感的部分，包括射频调度、链路控制、低功耗连接维护，以及与主应用处理器的协调。

这种架构适用于电池供电的联网产品。借助异构多核设计，SF32 无需因每个无线事件都唤醒主应用 CPU：应用处理器负责产品逻辑和面向用户的功能，低功耗的蓝牙处理器或常开处理器负责维持无线链路。

低功耗处理器可供应用代码使用的程度因芯片系列而异。请先查看下方的系列对比，并针对具体型号核实 SDK 支持的任务分配方式。

当你需要了解蓝牙时序和控制器（Controller）固件运行在哪个处理器上、所选系列的低功耗核心是否可编程，或联网产品如何让应用 CPU 睡眠时，请阅读本文。有关服务设计和产品级蓝牙集成，请参阅蓝牙概览。

专用蓝牙处理器的价值¶

蓝牙并不是偶尔在后台运行的软件协议。联网设备必须满足严格的射频时序要求，包括广播、扫描、连接事件、数据包交换、音频传输、加密，以及与其他系统活动共存。

专用蓝牙子系统将这些对时序敏感的无线职责与主应用工作负载分离，可带来以下实际优势：

• 降低已连接待机状态下的平均功耗。
• UI、图形、音频或 AI 负载较高时，仍保持可靠的射频时序。
• 控制器侧可处理射频事件，无需每次都唤醒应用 CPU。
• 应用固件与协议控制固件分工更清晰。
• 更好地支持产品在主 CPU 睡眠时保持连接。

这种分工对可穿戴和便携产品尤其重要。设备大部分时间可以保持低功耗连接，仅在发生用户输入、传感器事件、显示更新、音频活动或手机同步时唤醒。

这些是架构带来的设计空间，并不保证某个功耗或唤醒时间。主机协议栈的运行位置、中断、时钟启动、睡眠策略和应用数据量都会影响实测结果。应使用目标固件和实际工作负载测量电流及响应时间。

在 SF32 系统中的位置¶

简化的 SF32 无线架构如下：

应用处理器
  - 产品固件
  - UI 与图形
  - 音频应用逻辑
  - 用户服务
        │
        ▼
蓝牙主机（Host）/ 系统服务
        │
        ▼
蓝牙处理器 / 控制器固件
  - 链路层时序
  - 射频调度
  - 低功耗连接事件
  - 控制器侧协议处理
        │
        ▼
蓝牙射频与 RF 前端

主机（Host）、控制器（Controller）和应用固件之间的具体分工取决于 SDK、协议栈配置和产品需求。但在概念上，不能把主应用处理器视为参与蓝牙运行的唯一 CPU。蓝牙子系统拥有独立的执行上下文，设计目标是在保证无线行为确定性的同时降低功耗。

器件系列差异¶

SF32LB 各系列采用不同的低功耗处理器配置。请务必根据所用具体器件查阅数据手册和 SDK 文档。

思澈科技（SiFli）的 SF32LB52x HAL 指南说明，LCPU 运行蓝牙协议栈，不对应用开放。SF32LB55x、SF32LB56x 和 SF32LB58x 的 HAL 指南则介绍了在 LCPU 上运行 BLE、传感器处理等功耗敏感功能的方式。对于 SF32LB57x，SDK 的 ACPU 使用指南说明其采用 HCPU、ACPU、LCPU 架构，并将 BLE、传感器处理等任务归于 LCPU，但未说明用户能否在 LCPU 上运行其他自定义任务及其支持范围。不要将某一系列 LCPU 的可编程能力套用到其他系列。针对具体料号，先从数据手册确认内核配置，再检查计划使用的 SDK 版本和开发板配置是否支持在 LCPU 上运行目标应用任务。若没有该版本与开发板组合的明确资料，应将此任务分配标记为“未确认”；在方案定型前还要核实可用内存和调度限制。

该 ACPU 指南还区分了应用核的职责：SF32LB57x 的 ACPU 用于音频和图形处理，SF32LB58x 的 ACPU 则用于音频 DSP。这些职责不同于蓝牙控制器工作；具体任务分配应以目标开发板和 SDK 为准。

表中的蓝牙能力是对系列级资料的概括，并不代表每个料号或 SDK 构建都支持所有蓝牙应用规范（Profile）。

思澈科技（SiFli）的 SF32LB52x 数据手册、SF32LB55x 数据手册、SF32LB56x 数据手册和 SF32LB58x 数据手册列出了表中的 BLE 或双模能力。SDK 的蓝牙信令测试指南涵盖 BR/EDR 和 BLE 测试，并列出 SF32LB57x。具体 Profile、功能和配置支持，请以目标料号和 SDK 版本为准。

应用可编程性与控制器固件¶

LCPU 可运行应用任务，并不意味着用户可以访问蓝牙控制器源码或替换其无线协议栈。固件更新、补丁机制、可用内存和调度限制均取决于具体芯片与 SDK。

• 低功耗应用开发。 在支持的配置下，将合适的传感器采集、轻量处理和系统管理任务放到 LCPU，为栈空间、任务执行时间及与 HCPU 的通信预留预算。
• 控制器维护与定制。 使用厂商针对目标芯片和 SDK 提供的固件更新及补丁机制。应用内核可编程，并不能证明控制器专有源码或替代无线协议栈可用；这些能力需要另行向思澈科技（SiFli）确认。

仅用于控制器的配置也可能支持厂商固件更新，不能把它理解成永远不可变的固件。控制器变更后，应验证这些变更对蓝牙资格验证、互操作性、主机/控制器兼容性及 OTA 故障恢复的影响。故障恢复所需的版本回退，与禁止安装存在漏洞的旧固件这一安全策略，应分别设计。

BLE 与双模蓝牙¶

根据系列不同，SF32 器件可能仅支持低功耗蓝牙（BLE），也可能同时支持经典蓝牙和 BLE，即双模蓝牙。

低功耗蓝牙¶

BLE 针对低功耗数据交换进行优化，常用于：

• 运动手环和智能手表。
• 健康传感器和可穿戴设备。
• 手机通知和配套应用。
• 传感器同步。
• 信标和位置感知设备。
• 低功耗控制和配置通道。

BLE 通信通常以间歇方式进行，并由事件触发，因此很适合由低功耗的蓝牙处理器维护。

经典蓝牙与双模设计¶

双模蓝牙在 BLE 之外增加经典蓝牙能力，适用于：

• 蓝牙音频配件。
• 无线适配器和模组。
• 需要兼容现有经典蓝牙 Profile 的设备。
• 将 BLE 控制与经典蓝牙音频或数据功能结合的产品。

双模运行对系统资源的要求可能高于仅支持 BLE 的方案，因为音频和传统 Profile 可能对吞吐量、延迟（latency）或共存提出更高要求。专用蓝牙子系统有助于隔离这些时序敏感任务，避免主 CPU 的负载峰值影响其运行。

蓝牙音频与 LE Audio¶

蓝牙音频对系统架构提出了更高要求，因为产品需要同时处理射频时序、缓冲、编解码、时钟同步，有时还要刷新用户界面。

设计良好的 SF32 蓝牙音频系统通常采用以下职责划分：

• 蓝牙处理器负责控制器侧射频和链路时序。
• 应用处理器负责产品逻辑、UI 和高层音频行为。
• I2S、PDM、ADC 或 DAC 等音频接口负责在系统中输入和输出采样数据。
• DMA 和缓冲策略降低连续音频流对 CPU 的开销。

对于 LE Audio 或其他现代蓝牙音频应用，固件架构、协议栈支持、编解码器选择、内存带宽和电源管理策略都会影响最终效果。思澈科技（SiFli）的 SF32LB56x 和 SF32LB58x 数据手册明确列出 BLE Audio 支持；仅支持 BLE 或双模蓝牙，并不代表支持 LE Audio。具体 Profile、编解码器和 SDK 实现路径仍取决于料号和 SDK 版本，采用 LE Audio 前应逐项核实。蓝牙处理器提供时序基础，但产品的实际表现仍取决于 SDK 和应用设计。

低功耗运行¶

当主应用处理器能在无线链路保持活动时睡眠，蓝牙子系统的价值最大。在已连接待机状态下，系统可能只需在以下有意义的事件发生时唤醒应用处理器：

• 收到通知或命令。
• 连接状态变化。
• 计划的同步任务。
• 音频流开始或停止。
• 传感器或用户输入事件。
• 固件更新或配网操作。

这样可以让主 CPU 尽可能长时间保持在低功耗状态。蓝牙处理器和射频会在计划的连接事件中唤醒，完成必要的协议处理后，再让系统返回较低功耗状态。

实际功耗取决于连接间隔、发射功率、广播行为、睡眠模式、晶振配置、射频布局、固件策略，以及应用处理器的唤醒频率。

主机（Host）、控制器（Controller）与应用的职责边界¶

蓝牙软件通常分为两个主要层次：

在 SF32 系统中，控制器侧职责与蓝牙处理器和射频子系统紧密关联。根据协议栈架构不同，主机侧可能运行于应用处理器、系统固件，或由多个 SDK 组件共同承担。

对应用开发者而言，最重要的一点是蓝牙行为跨越 CPU 边界。共享内存、处理器间消息、事件和 SDK API 都是产品架构的一部分。应将蓝牙视为完整子系统，而不只是链接到主应用中的一个库。

与应用处理器的交互¶

应用处理器通常控制产品级行为：

• 启动和停止广播。
• 创建或接受连接。
• 管理 GATT 服务和特征。
• 处理配对、绑定和安全策略。
• 与手机或网关交换应用数据。
• 在蓝牙状态变化时更新 UI。
• 协调音频流、传感器和功耗模式。

蓝牙处理器负责维持连接所需的底层工作。两侧之间的通信通常由 SDK API、事件、队列或处理器间通信机制进行抽象。

良好的应用设计应避免为不必要的工作唤醒主 CPU。在可行时批量处理事件，选择合适的连接参数，并在提供事件回调时避免高频应用轮询。

射频与时钟注意事项¶

蓝牙处理器本身无法保证良好无线性能，外围硬件设计同样重要。射频布局、天线调谐、时钟精度、电源完整性和生产校准都会影响通信距离、灵敏度、发射功率和连接稳定性。

重要硬件注意事项包括：

• 使用推荐的射频匹配网络和天线布局。
• 射频走线应短、保持受控阻抗，并与噪声信号充分隔离。
• 遵循硬件设计指南中的晶振要求。
• 为射频和时钟电路提供低噪声供电，并在器件附近布置去耦电容。
• 保留生产测试接口，用于射频校准和固件下载。
• 避免高速显示、存储或开关电源走线靠近敏感射频路径。

软硬件团队都应将蓝牙性能视为系统属性。固件参数无法完全弥补不良射频布局或不稳定时钟。

与其他工作负载共存¶

SF32 通常同时运行蓝牙、图形、音频、传感器、存储，有时还会连接外部 Wi-Fi。这些子系统会共享电源、时钟、内存带宽、引脚和 CPU 资源。

常见共存问题包括：

• 显示刷新或 PSRAM 流量影响可用内存带宽。
• 音频 DMA 和蓝牙音频缓冲区需要稳定时序。
• 传感器中断过于频繁地唤醒应用处理器。
• 外部 Wi-Fi 或其他射频源影响蓝牙性能。
• 长临界区或关闭中断延迟主机侧蓝牙处理。

蓝牙处理器能够降低时序受干扰的风险，但无法消除所有共享资源瓶颈。具有音频、丰富 UI 或外部无线连接的产品，应在符合实际情况的最坏工作负载下测试。

典型应用¶

蓝牙处理器是许多 SF32 产品类别的核心：

• 蓝牙模组和串行适配器。
• 入门级智能手表和运动手环。
• BLE 健康传感器和可穿戴设备。
• 蓝牙音频配件。
• 智能胸牌和电子价签。
• 手机连接的仪表盘和 HMI 设备。
• 智能家居控制和配套应用产品。
• 传感器同步和数据记录设备。

选择具体 SF32 型号时，应先确定产品只需要 BLE 还是需要双模蓝牙，再评估音频、显示、内存容量和用户可编程低功耗处理能力。

实用设计建议¶

设计 SF32 蓝牙固件时，应先定义产品连接行为：

• 产品只需要 BLE，还是需要双模蓝牙？
• 是否需要蓝牙音频？
• 所需连接间隔、延迟和吞吐量是多少？
• 主应用处理器需要多久唤醒一次？
• 哪些事件必须将系统从深度睡眠（Deep Sleep）或待机（Standby）状态唤醒？
• 传感器或 UI 任务是否会与蓝牙时序竞争？
• 射频通信距离和发射功率目标是什么？
• 如何完成量产固件下载和射频校准？

稳健的设计通常需要结合蓝牙处理器、谨慎选择连接参数、事件驱动的应用代码、低功耗状态规划，以及良好的射频硬件布局。

要点¶

• SF32LB 器件使用专用蓝牙或低功耗处理器子系统，使无线运行既可靠又省电。
• SF32LB52x 的 LCPU 专用于蓝牙控制器；SF32LB55x、SF32LB56x 和 SF32LB58x 可在 SDK 支持的配置中将应用任务分配给 LCPU。SF32LB57x 使用 LCPU 处理蓝牙及对功耗敏感的任务，但计划运行的每项用户任务，都应在目标 SDK 和开发板上核实是否受支持。
• 可编程 LCPU 支持在 SDK 约束内运行应用任务；控制器协议栈源码是否开放、能否定制，需要另行确认。使用厂商支持的更新机制，并验证控制器变更。
• BLE 针对低功耗联网产品优化；双模蓝牙增加经典蓝牙能力，包括音频和传统 Profile 支持。
• 蓝牙处理器可以在连接、广播和计划射频事件持续运行时，帮助主应用 CPU 保持睡眠。
• 良好蓝牙性能同时依赖固件架构和硬件设计，包括射频布局、时钟、电源、天线调谐和校准。
• 应将蓝牙视为具有主机/控制器边界、处理器间通信、电源策略和共享资源约束的完整子系统。

最后更新: 2026-10-21