人工智能如何赋能物联网?EDGE AI →
  1. Home
  2. 新闻

    三种蓝牙架构实现方案(蓝牙协议栈方案)

三种蓝牙架构实现方案(蓝牙协议栈方案) 2024-03-13

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

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

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

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

 架构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开源蓝牙协议栈也支持这种架构。

架构2:单芯片整体方案

架构2:单芯片整体方案

手机周边蓝牙设备是蓝牙另外一个非常重要的应用场合,通常手机周边设备功能比较简单,但对成本非常敏感,因此采用一颗芯片来实现整个蓝牙协议栈就是非常明智的选择,即把蓝牙协议栈所有功能都放在一颗芯片上。

也就是说,host和controller都放在同一颗芯片上,由于host和controller都在同一颗芯片上,因此物理HCI就没有存在的必要性,host和controller之间直接通过API来交互。像Nordic的蓝牙协议栈Softdevice,就是采用这种模式。当然Zephyr也支持这种架构。

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

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

还有一些蓝牙设备功能比较强大,它需要一颗功能非常强大的MCU来做主应用,而蓝牙SoC只是整个系统的一部分,这种情况下,大部分蓝牙协议栈功能或者整个蓝牙协议栈功能都是跑在蓝牙SoC中,而蓝牙应用则跑在主MCU中,主MCU和蓝牙SoC之间的通信协议由厂商自己定义,因此称为自定义双芯片架构方案。

这种方案也非常常见,可以说,除了架构1和架构2之外的架构,都可以称为架构3。

架构3里面有一种非常特殊的情况,即主MCU和蓝牙SoC之间采用了HCI接口进行通信,由于这里的HCI只是用来进行物理通信,而通信的主体不是host和controller,通信包应用数据也不遵循蓝牙核心规格规范,因此不能把它看成第1种架构,Nordic的serialization方案就属于这种特殊情况。

其他推荐阅读

订阅Nordic新闻简报

了解最新信息!订阅后即可获取最新Nordic及物联网资讯

立即订阅