二轮车蓝牙系统方案对比 — HCI 模组 vs MCU 蓝牙模组

投屏版 (Mirror) 与非投屏版 (Non-Mirror) 的架构选择与模组选型分析

1. 模组类型定义：HCI vs MCU 蓝牙

选择蓝牙模组之前，先厘清两种根本不同的架构：

1.1 HCI 蓝牙模组

复制代码

+--------------------------+
|     Host (SoC / MCU)     |     <-- BT协议栈 + Profile + 应用程序全在这
|  BT Stack (BlueZ/自研)    |
|  L2CAP / SDP / RFCOMM     |
|  A2DP / HFP / AVRCP       |
|  Audio Codec (SBC/LC3)    |
+----------HCI(UART)--------+
|     HCI 蓝牙模组           |     <-- 只有 Baseband + RF
|  Link Manager + BB + RF   |
|  无协议栈，无Profile        |
+---------------------------+

特征：

模组只负责物理层（基带+射频），通过 HCI 信道上送所有协议事件
完整蓝牙协议栈运行在 Host 端（SoC 或 MCU）
Host 能控制每一层协议行为：SCO 路由、SBC 参数、Link Policy 等
Host 资源要求：需要能跑完整 BT Stack（Linux 上约 2-5MB Flash/RAM；MCU 厂商 SDK 自研 stack 约 500KB-1MB）

1.2 MCU 蓝牙模组

复制代码

+--------------------------+
|     Host (MCU / SoC)     |     <-- 只发 AT 命令
|  UART <-> AT Command     |        不需要任何 BT 协议栈
+-------UART(AT cmd)-------+
|     MCU 蓝牙模组          |     <-- 模组内部 MCU 跑完整 BT 协议栈
|  内部 MCU (Cortex-M)      |
|  BT Stack (全部)          |
|  A2DP / HFP / SPP / etc   |
|  Baseband + RF            |
|  (可选) I2S 音频接口       |
+---------------------------+

特征：

模组内部自带 MCU，蓝牙协议栈和应用程序都跑在模组内部
Host 通过 AT 命令高层控制（接听/挂断/音乐播放/音量/对讲开关）
Host 完全不需要跑任何 BT 协议栈
Host 资源要求：极低，任何 MCU 都能胜任（只要一个 UART + 发送 AT 命令）

1.3 关键差异速查

|-------------|-------------------------|------------------------|
| 维度 | HCI 蓝牙模组 | MCU 蓝牙模组 |
| BT Stack 位置 | Host 端 | 模组内部 MCU |
| Host 接口 | UART-HCI (Binary) | UART-AT (Text/Binary) |
| Host 最低要求 | MCU (500KB-1MB Flash) | 任意 MCU (Cortex-M0+ 即可) |
| Host 开发量 | 中/大（BT 协议栈集成+Profile） | 小（AT命令调度） |
| 灵活性 | 极高（自定义Profile/Codec/路由） | 中等（受限于AT命令集和固件） |
| 音频路由控制 | Host 直接控制 I2S/PCM | 模组内部控制，Host 只能间接影响 |
| 典型 BOM 成本 | 低（模组简单，仅RF+BB） | 中（模组内含MCU） |
| 典型场景 | 车载座舱、高端仪表、WiFi-BT Combo | 智能家居、简单配件 |

2. 产品需求分层

二轮车蓝牙系统按复杂度分两级：

|-------------------------------|-------------------------|-----------------------|
| 需求 | 投屏版 (Mirror) | 非投屏版 (Non-Mirror) |
| 手机投屏 (CarPlay / Android Auto) | 需要 | 不需要 |
| TFT 彩色屏幕 (7") | 需要 | 不需要（LED/段码屏） |
| 手机音乐推到头盔 | 需要 | 需要 |
| 手机免提通话 | 需要 | 需要 |
| 双头盔独立音量 | 需要 | 需要 |
| 前后座对讲 | 需要 | 需要 |
| 导航语音提示 | 屏幕导航 + TTS | TTS 语音播报 |
| Host 芯片 | Vehicle SoC (Linux) | MCU (RTOS) |
| WiFi | 需要 (CarPlay 视频链路) | 可选 (OTA/诊断，不投屏) |

核心矛盾

投屏版的 SoC 资源充足，可以跑 BT 协议栈，HCI 模组和 MCU 蓝牙模组都可以用。非投屏版的 MCU 方案受限于两个技术约束：

单 HCI 模组不可行：市面上没有任何模组能承载 3 路 A2DP 音频流并发
双 HCI 模组不可行：MCU 上两套 BT Stack 实例必然符号重定义

因此非投屏版有头盔需求的，只能用双 MCU 蓝牙模组。

这引出了直接的方案对比问题：

投屏版：用 HCI 还是 MCU-BT？ 非投屏版：HCI 还是 MCU-BT？单模组还是双模组？

3. 投屏版方案对比 (SoC Host)

投屏版 Host 是 Vehicle SoC（RK3568 / MT8666 / i.MX8M Plus），运行 Linux。SoC 资源充足，HCI 模组和 MCU 蓝牙模组都可以选。

3.0 投屏版整体架构概览

上图展示了投屏版的核心架构：WiFi 投屏链路（CarPlay H.264 -> GPU -> MIPI DSI -> TFT）与蓝牙音频链路（HCI 模组 A/B 管理手机和头盔）完全独立并行。

关键前提 ：所有投屏版方案中，CarPlay / Android Auto 的 WiFi 投屏链路始终独立运行在 SoC 上，与蓝牙模组选型无关。WiFi 负责 H.264 视频流传输，蓝牙负责音频和通话，这两条链路是并行的。下面讨论的 HCI vs MCU-BT 选型，只是决定"蓝牙音频链路"怎么走，不影响 WiFi 投屏能力。

3.1 方案 A：SoC + 双 HCI 模组（全灵活方案）

复制代码

Vehicle SoC (Linux)
                      +------------------------------+
  Phone               |   BlueZ BT Stack (完整)       |
  A2DP Source --------+-- HCI(UART1) -- [HCI模组A]   |
  HFP AG              |   A2DP Sink + HFP HF         |
                      |   SBC 解码 -> PCM Buffer      |
                      |                              |
                      |   音频路由 (ALSA / PulseAudio) |
                      |   PCM Buffer -> SBC 编码      |
                      |                              |
                      |   BlueZ BT Stack (完整)       |
  Helmet 1 (Sink) ----+-- HCI(UART2) -- [HCI模组B]   |
  Helmet 2 (Sink) ----+   A2DP Source x2 + HFP AG    |
                      +------------------------------+

特征：

两个 HCI 模组只做射频，所有协议栈在 SoC 的 BlueZ 上
SoC 直接控制 SBC 编解码：Phone 侧解码后 PCM Buffer 可直接送给 Helmet 侧编码（SBC 零拷贝直通可能）
音频路由完全在 ALSA/PulseAudio 层面控制，延迟最优
对讲实现：SoC 直接管理 SCO 链路，做音频 mixing

优势：

最大灵活性：可以自定义任何 Profile 行为、Codec 参数、音频路由策略
延迟最优：SBC decode -> PCM -> SBC encode 链路最短，SoC 内部 DMA 搬运
无需受限于模组固件：想加新功能直接改 SoC 代码
HCI 模组 BOM 成本最低（只含 RF + Baseband）

劣势：

SoC 端开发量巨大：BlueZ + D-Bus + PulseAudio
需要蓝牙协议栈深度能力
调试复杂度高
对讲双 SCO 能力依赖 Controller 芯片支持

适用：有自研 BT 协议栈能力的大厂，追求极致性能和差异化。

3.2 方案 B：SoC + HCI(手机侧) + MCU-BT(头盔侧)（混合方案）

复制代码

Vehicle SoC (Linux)
                      +------------------------------+
  Phone               |   BlueZ BT Stack              |
  A2DP Source --------+-- HCI(UART1) -- [HCI模组A]   |
  HFP AG              |   A2DP Sink + HFP HF         |
                      |   SBC 解码 -> PCM Buffer      |
                      |                              |
                      |   音频路由 (ALSA)              |
                      |   PCM Buffer -> I2S OUT       |
                      |                              |
                      |   UART AT cmd dispatcher      |
  Helmet 1 (Sink) ------- [MCU-BT模组B]               |
  Helmet 2 (Sink) ------- (内部跑完整BT协议栈)           |
                      |   I2S IN <- PCM from SoC      |
                      +------------------------------+

特征：

手机侧用 HCI：SoC 直接控制手机链路，SBC 编解码和音频输入可控
头盔侧用 MCU-BT：模组 B 独立处理双头盔推送、对讲、HFP AG，SoC 只需发 AT 命令
在"灵活性"和"开发效率"之间取平衡点

为什么手机侧选 HCI 而不是 MCU-BT？

手机侧链路是系统核心输入，需要在 SoC 层面做音频处理（PBAP 通讯录解析、来电弹窗联动 UI、SBC 解码后做 EQ/音量归一化）
如果走 MCU-BT，I2S PCM 出来后 SoC 只能"听到"音频，拿不到 SBC 原始参数、来电 PBAP 数据等元信息

为什么头盔侧选 MCU-BT 而不是 HCI？

头盔侧逻辑相对固定：双路 A2DP 推送 + 对讲转发，标准化程度高
MCU-BT 模组已封装好双 Source + 独立音量 + 对讲逻辑，SoC 侧零开发
避免 SoC 同时跑两套 BT Stack（虽然 BlueZ 支持多 Controller，但调试复杂度翻倍）

优势：

手机侧灵活可控，头盔侧简单省力
开发量适中：只集成一个 HCI 协议栈，另一个用 AT 命令

劣势：

非对称架构，维护两套不同的控制面（HCI + AT cmd）

适用：大多数投屏版厂商的务实选择。

4. 非投屏版方案对比 (MCU Host)

非投屏版 Host 是 MCU（开阳 AMT630 / STM32F7 / NXP S32K / 国产 Cortex-M4/M7），运行 bare-metal 或 RTOS。HCI 模组和 MCU 蓝牙模组都可以选，取决于 MCU 是否有 BT 协议栈。

为什么非投屏版不能走 HCI 路线？

非投屏版用 HCI 模组面临两个致命问题：

1. 单 HCI 模组：3 路 A2DP 音频流并发不可行。 Controller 虽然可以建立 3 路 ACL 连接，但 A2DP 不是"建立连接就完事"------每路 A2DP 音频流都存在持续的 SBC 编码/解码 + eSCO 调度 + ACL 数据包收发 。1 路 A2DP Sink（解码手机音频）+ 2 路 A2DP Source（分别编码推流给两个头盔）= 3 路音频流同时在同一个 Controller 上处理。市面上的 HCI 模组（不管是 RTL8762、AB156x 还是 QCC 系列）都没有支持 3 路 A2DP 并发的能力------这不是协议规范问题，是芯片算力和带宽的物理天花板。

2. 双 HCI 模组：符号重定义不可行。 两个 HCI 模组意味着 MCU 上需要两套 BT 协议栈实例。而嵌入式 BT Stack（无论是厂商 SDK 还是自研）通常以全局变量 + 静态函数 的设计实现：g_bt_state、hci_event_handler()、l2cap_rx_cb 等都是全局符号。编译链接时第二份代码全部符号重定义，链接器直接报错。

**结论：非投屏版有头盔需求的，唯一可行路径是双 MCU 蓝牙模组。**每个模组独立跑协议栈，互不干扰。

4.1 方案 D：MCU + 双 MCU 蓝牙模组（标准方案）

复制代码

Host MCU (Cortex-M4)
                      +------------------------------+
  Phone               |  UART1 AT cmd                 |
  A2DP Source ----------- [MCU-BT模组A]               |
  HFP AG              |  (A2DP Sink + HFP HF)        |
                      |  I2S OUT -> PCM               |
                      |                              |
                      |  DMA / I2S Router             |
                      |  PCM IN -> I2S IN             |
                      |                              |
                      |  UART2 AT cmd                 |
  Helmet 1 (Sink) ------- [MCU-BT模组B]               |
  Helmet 2 (Sink) ------- (A2DP Source x2 + HFP AG)   |
                      +------------------------------+

特征：

MCU 只做两件事：发 AT 命令 + 透传 I2S 音频
模组 A 负责从手机收音频，模组 B 负责推送到头盔
与投屏版方案 B 头盔侧蓝牙系统完全兼容

音频路由：

MCU-BT模组A (I2S OUT) --> MCU DMA buffer --> MCU-BT模组B (I2S IN)

MCU 做 I2S 直通：延迟 ~1-2ms，但 MCU 需要两路 I2S

无 I2S 的子变体：模组 A 的 I2S OUT 直连到模组 B 的 I2S IN（模块间直连），MCU 完全不参与音频搬运。放弃 MCU 端音频处理，但进一步降低 MCU 选型要求。

优势：

MCU 不跑 BT 协议栈，开发量极低（只写 AT 命令）
模组厂商保证 BT 稳定性
与投屏版方案 B 头盔侧模组完全复用

劣势：

两颗 MCU 蓝牙模组 BOM 较高（$14-22）
受限于模组 AT 命令集和固件
音频延迟比 HCI 方案多 ~7ms（二次编解码）

适用：无 BT 协议栈积累、追求最快上市的团队。

4.2 方案 E：MCU + 单 MCU 蓝牙模组（极简方案，无头盔）

复制代码

Host MCU
                      +--------------------+
  Phone               |  UART AT cmd       |
  A2DP Source ----------- [MCU-BT模组]      |
  HFP AG              |  A2DP Sink + HFP HF|
                      +--------------------+
                               |
                          I2S OUT -> 外接 Speaker

特征：

只有手机侧蓝牙，连接手机播放音乐/接打电话
音频直接给仪表扬声器，不推头盔
无头盔共享、无对讲、无双路推送

适用：入门级电动自行车，仪表只做蓝牙播放器，BOM $6-10。

4.3 非投屏版方案速览

|--------|-----------|--------------|---------|-----------|
| 方案 | 模组 | MCU BT工作 | BOM | 适合 |
| D | 2x MCU-BT | 只发 AT 命令 | $14-22 | 有头盔需求标准方案 | | E | 1x MCU-BT | 只发 AT 命令 |$ 6-10 | 入门级, 无头盔 |

5. 全方案对比矩阵

|----------------------|----------------------|-------------------|-----------------------|-----------------------|
| 维度 | 方案A SoC+双HCI | 方案B SoC混合 | D MCU+双MCU-BT | E MCU+单MCU-BT |
| Host | SoC(Linux) | SoC(Linux) | MCU(RTOS) | MCU(RTOS) |
| BT Stack | BlueZ 全栈 | 混合 (HCI+AT) | 无 (AT only) | 无 (AT only) |
| BT开发量 | 极高 (51-75天) | 中 (37-58天) | 低 (21-36天) | 极低 (10-15天) |
| 投屏 | 支持 | 支持 | 不支持 | 不支持 |
| WiFi | SoC自带 | SoC自带 | 不需要 | 不需要 |
| 3路A2DP并发 | 双模组分担 | 头盔侧MCU-BT | 双模组分担 | N/A (无头盔) |
| Phone<->Helmet | SoC DMA直通 | PCM+I2S | 双模组I2S | 无头盔 |
| 音频延迟 | 最优 (31-66ms) | 优 (35-78ms) | 中等 (38-83ms) | 最优 (31-66ms) |
| SBC零拷贝 | 可能 | 不可能 | 不可能 | N/A |
| 模组BOM | 低 ( $8-14) | 中 ($ 11-18) | 中 ( $14-22) | 极低 ($ 6-10) |
| 供应商锁定 | 低(HCI标准) | 中(模组B锁定) | 高(私有AT) | 高(私有AT) |
| 目标价位 | $3,000+ |$ 3,000+ | $1,000-3,000 | \<$ 1,000 |

6. 音频路由对比分析

6.1 各方案音频延迟链路

方案 A（HCI 架构）--- 最优延迟，单次编解码：

复制代码

Phone A2DP encode:   ~5-15ms
  -> RF:              ~5-10ms
  -> Host SBC decode: ~2-3ms  (SoC DSP / MCU)
  -> PCM buffer:      ~0ms     (DMA 直通，零拷贝)
  -> Host SBC encode: ~2-3ms
  -> RF:              ~5-10ms
  -> Helmet decode:   ~2-5ms
  -> Helmet buffer:   ~10-20ms
====================================
Total:                ~31-66ms

HCI 方案的核心优势：SBC decode -> PCM -> SBC encode 在同一 Host 内存空间完成，无 I2S 物理传输。

方案 D（双 MCU-BT）--- 二次编解码，额外延迟：

复制代码

Phone A2DP encode:     ~5-15ms
  -> RF:                ~5-10ms
  -> MCU-BT A decode:   ~5-10ms  (模组内 MCU 解码)
  -> I2S transport:     ~1-3ms
  -> MCU-BT B encode:   ~5-10ms  (模组内 MCU 编码)
  -> RF:                ~5-10ms
  -> Helmet decode:     ~2-5ms
  -> Helmet buffer:     ~10-20ms
====================================
Total:                  ~38-83ms

方案 D 的额外 ~7ms 来自模组间 I2S 物理传输 + 二次 SBC 编解码。

6.2 I2S 音频路由方式

|-------------|--------|--------|----------------------|
| 路由方式 | 方案 | 延迟 | 音频处理能力 |
| Host DMA 直通 | A | 0ms | 支持 EQ/Mixing/Ducking |
| MCU I2S 转发 | D | +1-3ms | 支持简单 Mixing |
| 模组间 I2S 直连 | D子变体 | <1ms | 不支持任何处理 |
| SoC I2S 输出 | B | +3-5ms | 支持 SoC 端处理 |

7. 模组选型要点

7.1 HCI 蓝牙模组选型（用于方案 A / B）

|--------|--------------|------------------------|
| 参数 | 建议值 | 理由 |
| BT 版本 | 5.2+ 双模 | 支持 LE Audio ready |
| HCI 接口 | UART 3Mbps+ | HCI 事件/命令带宽需求 |
| 音频接口 | 不需要 | Host 跑 SBC 编解码，数据走 HCI |
| SCO 支持 | 至少 1 路 eSCO | HFP 通话需要 |
| 工作温度 | -40 ~ +85 C | 车载要求 |

常见可参考的芯片系列：Realtek RTL8762 / Airoha AB156x / Qualcomm QCC30xx（在 HCI mode）等。WiFi-BT Combo（如 RTL8723 / MT7663）通过 SDIO WiFi + UART HCI 也可用于投屏版 SoC 侧，但在非投屏 MCU 场景下因 3 路 A2DP 并发不可行而不适用。

7.2 MCU 蓝牙模组选型（手机侧，用于方案 D / E）

|--------|------------------|-----------------------------------|
| 参数 | 建议值 | 理由 |
| BT 版本 | 5.1+ 双模 | 兼容手机端 BT Classic |
| 协议栈 | 模组内部全栈 | A2DP Sink + HFP HF + AVRCP + PBAP |
| 音频接口 | I2S OUT (Master) | 输出解码后 PCM 给 Host |
| 音频编码 | SBC + (可选) AAC | 兼容 iPhone (AAC) 和 Android (SBC) |
| 控制接口 | UART AT 命令 | Host 通过 AT 命令控制 |
| 通讯录同步 | 支持 PBAP | 来电显示需要 |
| 免提通话 | 支持 HFP 1.7+ | 含 wideband speech (mSBC) |

7.3 MCU 蓝牙模组选型（头盔侧，用于方案 B / D）

|-------------------|----------------|---------------------|
| 参数 | 建议值 | 理由 |
| 双 A2DP Source | 必须 | 同时推音频给两个头盔 |
| BT 版本 | 5.1+ 双模 | 兼容头盔端 BT Classic 芯片 |
| 音频接口 | I2S IN (Slave) | 接收 Host 送来的 PCM |
| 独立音量控制 | 必须 | 每个头盔独立 AVRCP 音量 |
| 对讲/Intercom | 必须 | 前后座实时语音对讲 |
| HFP AG role | 需要 | 头盔作为 HF 连接本模组 |
| SCO 通道数 | 至少 2 路 | 对讲需要双向 SCO |
| 控制接口 | UART AT 命令 | Host 通过 AT 命令控制对讲开关 |
| 音频编码 | SBC (双流) | 两个头盔各自独立的 SBC 流 |

注意：双 A2DP Source 是头盔侧模组的核心门槛。市面上很多 MCU 蓝牙模组只支持 1 路 A2DP Source，需要专门找支持双 Source 的型号。

8. 开发集成评估

8.1 各方案预估工时

|------------------|--------------------|------------------|-------------------------|
| 开发步骤 | 方案A (双HCI) | 方案B (混合) | D (MCU+双MCU-BT) |
| BT协议栈集成 | 15-20天 | 8-12天 | 0天 |
| A2DP/HFP Profile | 8-12天 | 5-8天 | 0天 |
| AT命令调度 | 0天 | 3-5天 | 3-5天 |
| 音频路由 (ALSA/I2S) | 8-12天 | 5-8天 | 5-8天 |
| MCU UART/I2S驱动 | 5-8天 | 5-8天 | 5-8天 |
| UI交互 | 5-8天 | 3-5天 | 3-5天 |
| 路测调优 | 10-15天 | 8-12天 | 5-10天 |
| 总计 | 51-75天 | 37-58天 | 21-36天 |

8.2 各方案周期与团队要求

|-----------------|------------------------|----------|
| 方案 | 推荐团队 | 适合 |
| A (SoC+双HCI) | >= 2 BT协议栈 + 1 音频 DSP | 大厂自研座舱系统 |
| B (SoC混合) | 1 BT协议栈 + 1 嵌入式 | 平衡型项目 |
| D (MCU+双MCU-BT) | 1 MCU嵌入式 | 非投屏有头盔需求 |
| E (MCU+单MCU-BT) | 1 MCU嵌入式 | 极低成本项目 |

9. 总结与选型建议

9.1 决策路径

复制代码

投屏版？
  ├── 是 -> 有 BT 协议栈团队？
  │         ├── 是 -> 追求极致延迟/差异化？
  │         │         ├── 是 -> 方案 A (SoC + 双HCI)
  │         │         └── 否 -> 方案 B (SoC + 混合)
  │         └── 否 -> 方案 B (SoC + 混合)
  │
  └── 否 -> 有双头盔需求？
            ├── 是 -> 方案 D (MCU + 双 MCU-BT)
            └── 否 -> 方案 E (MCU + 单 MCU-BT)

9.2 核心建议

投屏版优先方案 B：

- 方案 B（HCI + MCU-BT 混合）适合大多数投屏厂商，手机侧灵活可控，头盔侧省力
- 方案 A（双 HCI）只适合有深度 BT 协议栈积累的团队
- 投屏版不要用双 MCU-BT：SoC 已经在那了，没必要多花 BOM 买 MCU 蓝牙

非投屏版有头盔需求用方案 D：

- 双 MCU 蓝牙模组 + AT 命令，是非投屏版有头盔/对讲需求的唯一可行路径
- 研发量最低（21-36天），蓝牙协议栈稳定性由模组厂商保证
- 虽然 BOM 比单模组高 $6-8，但换来的是稳定可复用的蓝牙子系统

入门级用方案 E：

- 单 MCU 蓝牙模组 + AT 命令，放弃头盔/对讲功能
- 纯仪表蓝牙音箱场景，BOM 最低（$6-10），10-15 天搞定

音频延迟不是选型关键因素：

- 方案 D（双 MCU-BT）vs 方案 A（HCI）延迟差异约 7-17ms
- 真正的延迟瓶颈在蓝牙无线传输（15-30ms）和头盔端 Jitter Buffer（10-20ms）
- 不要为了省十几毫秒延迟而选择开发成本翻倍的方案

9.3 HCI vs MCU-BT 模组的根本取舍

|----------------|-------------------|
| 选 HCI | 选 MCU-BT |
| 投屏版 SoC Host | 非投屏 MCU (HCI 不可行) |
| 需要自定义协议行为 | 标准 A2DP/HFP 足够 |
| 需要 SBC DMA 零拷贝 | 不在意 7ms 额外延迟 |
| 有 BT 协议栈能力 | 只有嵌入式应用团队 |
| 追求 50+ 天深度研发 | 追求 21 天内上市 |

一句话总结：投屏版推荐 HCI+MCU-BT 混合（方案 B）；非投屏版有头盔需求只能用双 MCU 蓝牙模组（方案 D），单 HCI 模组无法承载 3 路 A2DP 并发，双 HCI 模组有符号重定义问题；入门级用单 MCU-BT（方案 E）。

二轮车蓝牙系统方案对比 — HCI 模组 vs MCU 蓝牙模组

目录

1. 模组类型定义：HCI vs MCU 蓝牙

1.1 HCI 蓝牙模组

1.2 MCU 蓝牙模组

1.3 关键差异速查

2. 产品需求分层

核心矛盾

3. 投屏版方案对比 (SoC Host)

3.0 投屏版整体架构概览

3.1 方案 A：SoC + 双 HCI 模组（全灵活方案）

3.2 方案 B：SoC + HCI(手机侧) + MCU-BT(头盔侧)（混合方案）

4. 非投屏版方案对比 (MCU Host)

4.1 方案 D：MCU + 双 MCU 蓝牙模组（标准方案）

4.2 方案 E：MCU + 单 MCU 蓝牙模组（极简方案，无头盔）

4.3 非投屏版方案速览

5. 全方案对比矩阵

6. 音频路由对比分析

6.1 各方案音频延迟链路

6.2 I2S 音频路由方式

7. 模组选型要点

7.1 HCI 蓝牙模组选型（用于方案 A / B）

7.2 MCU 蓝牙模组选型（手机侧，用于方案 D / E）

7.3 MCU 蓝牙模组选型（头盔侧，用于方案 B / D）

8. 开发集成评估

8.1 各方案预估工时

8.2 各方案周期与团队要求

9. 总结与选型建议

9.1 决策路径

9.2 核心建议

9.3 HCI vs MCU-BT 模组的根本取舍