三种蓝⽛架构实现⽅案（蓝⽛协议栈⽅案）
蓝⽛架构实现⽅案有哪⼏种？我们⼀般把整个蓝⽛实现⽅案叫做蓝⽛协议栈，因此这个问题也可以这么阐述：蓝⽛协议栈有哪些具体的架构⽅案？在蓝⽛协议栈中，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开源蓝⽛协议栈也⽀持这种架构。
里面包含具体那些协议?
架构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⽅案就属于这种特殊情况。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。