蓝牙 BLE 协议学习： 3种蓝牙架构实现方案（蓝牙协议栈方案）

导言

不同的蓝牙架构可以用在不同的场景中。从而协议帧的架构方案也会不同。

转载自：《三种蓝牙架构实现方案（蓝牙协议栈方案）》

蓝牙架构实现方案有哪几种？我们一般把整个蓝牙实现方案叫做蓝牙协议栈，因此这个问题也可以这么阐述：蓝牙协议栈有哪些具体的架构方案？在蓝牙协议栈中，host是什么？controller是什么？HCI又是什么？

大家都知道，不同的应用场景有不同的需求，因此不同的应用场景对蓝牙实现方案的要求也不一样，从而催生不同的蓝牙架构实现方案，或者说蓝牙协议栈方案。

架构1：host+controller双芯片标准架构

蓝牙是跟随手机而诞生的，如何在手机中实现蓝牙应用，是蓝牙规格首先要考虑的问题。如果你仔细阅读蓝牙核心规格，你会发现规格书更多地是站在手机角度来阐述的，然后“顺带”描述一下手机周边蓝牙设备的实现原理。如大家所熟知，手机里面包含很多SoC或者模块，每颗SoC或者模块都有自己独有的功能，比如手机应用跑在AP芯片上（一般而言，Android或者iOS开发者只需跟AP芯片打交道），显示屏，3G/4G通信，WiFi/蓝牙等都有自己专门的SoC或者模块，这些模块在物理上都会通过某种接口与AP相连。如果应用需要用到某个模块的时候，比如蓝牙通信，AP会自动跟蓝牙模块交互，从而完成蓝牙通信功能。市场上有很多种AP芯片，同时也有很多种蓝牙模块，如何保证两者的兼容性，以减轻手机的开发工作量，增加手机厂商蓝牙方案选型的灵活性，是蓝牙规格要考虑的事情。为此，蓝牙规格定义了一套标准，使得手机厂商，比如苹果，用一颗新AP替换老AP，蓝牙模块不需要做任何更改；同样用一颗新蓝牙模块换掉老蓝牙模块，AP端也不需要做任何更改。这个标准把蓝牙协议栈分成host和controller两部分，其中host跑在AP上，controller跑在蓝牙模块上，两者之间通过HCI协议进行通信，而且host具体包含协议栈那些部分，controller具体包含协议栈那些部分，两者之间通信的HCI协议如何定义，这些在蓝牙核心规格中都有详细定义，因此我把它称为双芯片标准方案。只要遵循这套标准，用户就可以随意替换Host或者Controller方案。当然，这种方案除了可以应用在手机中，也可以应用在任何其他设备中。AP芯片厂商一般会直接采用Bluez等开源协议栈来实现Host功能，而Controller部分大部分由蓝牙厂商自己来实现。另外，目前比较火的Zephyr开源蓝牙协议栈也支持这种架构。

HOST(AP 芯片) <--> 蓝牙 controller

架构2：单芯片整体方案

手机周边蓝牙设备是蓝牙另外一个非常重要的应用场合，通常手机周边设备功能比较简单，但对成本非常敏感，因此采用一颗芯片来实现整个蓝牙协议栈就是非常明智的选择，即把蓝牙协议栈所有功能都放在一颗芯片上，也就是说，host和controller都放在同一颗芯片上，由于host和controller都在同一颗芯片上，因此物理HCI就没有存在的必要性，host和controller之间直接通过API来交互。像Nordic的蓝牙协议栈Softdevice，就是采用这种模式。当然Zephyr也支持这种架构。

架构3：自定义双芯片架构

还有一些蓝牙设备功能比较强大，它需要一颗功能非常强大的MCU来做主应用，而蓝牙SoC只是整个系统的一部分，这种情况下，大部分蓝牙协议栈功能或者整个蓝牙协议栈功能都是跑在蓝牙SoC中，而蓝牙应用则跑在主MCU中，主MCU和蓝牙SoC之间的通信协议由厂商自己定义，因此称为自定义双芯片架构方案。这种方案也非常常见，可以说，除了架构1和架构2之外的架构，都可以称为架构3。架构3里面有一种非常特殊的情况，即主MCU和蓝牙SoC之间采用了HCI接口进行通信，由于这里的HCI只是用来进行物理通信，而通信的主体不是host和controller，通信包应用数据也不遵循蓝牙核心规格规范，因此不能把它看成第1种架构，Nordic的serialization方案就属于这种特殊情况。

主 MCU + 蓝牙有关的APP() <-自定义协议-> 蓝牙Soc