一

市面上大致有这几种蓝牙，其中优缺点也是我个人见解，大家一看就好，至于有不同意见，可以交流。

1. SOC蓝牙单芯片方案，

一般是半导体厂商半开源协议栈，基于特定的编译器，把蓝牙协议栈直接烧写到蓝牙芯片中（比如CSR BC4/5,CSR8670,CSR8675,TI CC2540，NRF51xxx,NRF52xxx，乐鑫ESP32等等），架构如下：

此类芯片一般可以直接做为MCU用，这类产品一般用于消费类电子，集成度很高，调调部参数可以直接使用，常见的有蓝牙耳机，一般蓝牙耳机之前CSR的芯片（CSRBC5/8670/8675）占很大的份额，现在CSR被高通并掉后，出来QCC3，QCC5系列，现在还有洛达，杰里的低成本方案，在有就是BLE smart设备，也有特有的方案

2. SOC蓝牙+MCU方案

就是在1）的基础上，通过特定的interface(UART居多)，发送自定义的command来达到想要的功能，比如发送0x01代表搜索周围设备，当然在产品中肯定不会定义这么简单的command，一般要加上command id + command len + command para data + command check sum来实现功能

架构如下：

此部分的应用一般用于外设功能相对于复杂，需要驱动很多外设，但是单芯片方案的性能达不到的情况下一般用这种方案

3. 蓝牙host + controller分开方案

这种应用算是蓝牙最复杂的应用，适用于蓝牙使用情景较复杂的情况下使用，比如车载蓝牙等。客户需要有很多蓝牙协议，比如蓝牙电话（HFP），蓝牙音频（A2DP），蓝牙音乐控制（AVRCP），蓝牙电话本（PBAP），蓝牙短信（MAP），BLE,HID，如果你说以上还能用soc做，那么再加上Carplay的IAP/IAP2，Android Auto的RFCOMM BT呢，基本以上就需要这种方案了。

其中Transport是一个协议，H2就是在USB的基础上的协议，H4,H5,BCSP是UART基础上的协议，当然还有SDIO。

四.总结

其实做多了，你就会发现每种架构都有每种的好处，并不是每周产品都需要套用某一种架构，需要考虑的方面很多，比如

1）项目需要的成本 2）项目的功能复杂度 3）项目的研发市场 4）项目硬件性能的考虑（rom,ram,codec等）

我大概列举下几种：

1）手机 -> 手机的蓝牙复杂应用，注定要用第3种方案，也就是蓝牙协议栈（host）在主芯片中，蓝牙芯片为HCI架构的

2）蓝牙音响，蓝牙耳机 -> 此种应用一般用单芯片方案就能hold住，比如CSR8670/8675/杰理蓝牙等，好处在于开发便捷

3）蓝牙手表 -> 手表要看功能复杂性，如果仅仅有时间显示，传感器交互，蓝牙，那么可以选择单芯片方案（也就是方案1），如果有网络等比较复杂的功能就要使用MCU+蓝牙芯片方案（也就是方案3）了

4）蓝牙手环，蓝牙心率带等 -> 基本上是单芯片方案