藍牙架構實現方案有哪幾種？我們一般把整個藍牙實現方案叫做藍牙協議棧，因此這個問題也可以這么闡述：藍牙協議棧有哪些具體的架構方案？在藍牙協議棧中，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方案就屬于這種特殊情況。

審核編輯 黃宇