藍牙架構(gòu)實現(xiàn)方案有哪幾種？我們一般把整個藍牙實現(xiàn)方案叫做藍牙協(xié)議棧，因此這個問題也可以這么闡述：藍牙協(xié)議棧有哪些具體的架構(gòu)方案？在藍牙協(xié)議棧中，host是什么？controller是什么？HCI又是什么？

大家都知道，不同的應用場景有不同的需求，因此不同的應用場景對藍牙實現(xiàn)方案的要求也不一樣，從而催生不同的藍牙架構(gòu)實現(xiàn)方案，或者說藍牙協(xié)議棧方案。

架構(gòu)1：host+controller雙芯片標準架構(gòu)

藍牙是跟隨手機而誕生的，如何在手機中實現(xiàn)藍牙應用，是藍牙規(guī)格首先要考慮的問題。如果你仔細閱讀藍牙核心規(guī)格，你會發(fā)現(xiàn)規(guī)格書更多地是站在手機角度來闡述的，然后“順帶”描述一下手機周邊藍牙設備的實現(xiàn)原理。

如大家所熟知，手機里面包含很多SoC或者模塊，每顆SoC或者模塊都有自己獨有的功能，比如手機應用跑在AP芯片上（一般而言，Android或者iOS開發(fā)者只需跟AP芯片打交道），顯示屏，3G/4G通信，WiFi/藍牙等都有自己專門的SoC或者模塊，這些模塊在物理上都會通過某種接口與AP相連。

如果應用需要用到某個模塊的時候，比如藍牙通信，AP會自動跟藍牙模塊交互，從而完成藍牙通信功能。市場上有很多種AP芯片，同時也有很多種藍牙模塊，如何保證兩者的兼容性，以減輕手機的開發(fā)工作量，增加手機廠商藍牙方案選型的靈活性，是藍牙規(guī)格要考慮的事情。

為此，藍牙規(guī)格定義了一套標準，使得手機廠商，比如蘋果，用一顆新AP替換老AP，藍牙模塊不需要做任何更改；同樣用一顆新藍牙模塊換掉老藍牙模塊，AP端也不需要做任何更改。這個標準把藍牙協(xié)議棧分成host和controller兩部分，其中host跑在AP上，controller跑在藍牙模塊上，兩者之間通過HCI協(xié)議進行通信，而且host具體包含協(xié)議棧那些部分，controller具體包含協(xié)議棧那些部分，兩者之間通信的HCI協(xié)議如何定義，這些在藍牙核心規(guī)格中都有詳細定義，因此我把它稱為雙芯片標準方案。

只要遵循這套標準，用戶就可以隨意替換Host或者Controller方案。當然，這種方案除了可以應用在手機中，也可以應用在任何其他設備中。

AP芯片廠商一般會直接采用Bluez等開源協(xié)議棧來實現(xiàn)Host功能，而Controller部分大部分由藍牙廠商自己來實現(xiàn)。另外，目前比較火的Zephyr開源藍牙協(xié)議棧也支持這種架構(gòu)。

架構(gòu)2：單芯片整體方案

手機周邊藍牙設備是藍牙另外一個非常重要的應用場合，通常手機周邊設備功能比較簡單，但對成本非常敏感，因此采用一顆芯片來實現(xiàn)整個藍牙協(xié)議棧就是非常明智的選擇，即把藍牙協(xié)議棧所有功能都放在一顆芯片上。

也就是說，host和controller都放在同一顆芯片上，由于host和controller都在同一顆芯片上，因此物理HCI就沒有存在的必要性，host和controller之間直接通過API來交互。像Nordic的藍牙協(xié)議棧Softdevice，就是采用這種模式。當然Zephyr也支持這種架構(gòu)。

架構(gòu)3：自定義雙芯片架構(gòu)

還有一些藍牙設備功能比較強大，它需要一顆功能非常強大的MCU來做主應用，而藍牙SoC只是整個系統(tǒng)的一部分，這種情況下，大部分藍牙協(xié)議棧功能或者整個藍牙協(xié)議棧功能都是跑在藍牙SoC中，而藍牙應用則跑在主MCU中，主MCU和藍牙SoC之間的通信協(xié)議由廠商自己定義，因此稱為自定義雙芯片架構(gòu)方案。

這種方案也非常常見，可以說，除了架構(gòu)1和架構(gòu)2之外的架構(gòu)，都可以稱為架構(gòu)3。

架構(gòu)3里面有一種非常特殊的情況，即主MCU和藍牙SoC之間采用了HCI接口進行通信，由于這里的HCI只是用來進行物理通信，而通信的主體不是host和controller，通信包應用數(shù)據(jù)也不遵循藍牙核心規(guī)格規(guī)范，因此不能把它看成第1種架構(gòu)，Nordic的serialization方案就屬于這種特殊情況。

審核編輯 黃宇