藍芽是跟隨手機而誕生的，如何在手機中實現藍芽應用，是藍芽規格首先要考慮的問題。如果你仔細閱讀藍芽核心規格，你會發現規格書更多地是站在手機角度來闡述的，然後「順帶」描述一下手機周邊藍芽裝置的實現原理。如大家所熟知，手機裡面包含很多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和controller都放在同一顆晶元上，由於host和controller都在同一顆晶元上，因此物理hci就沒有存在的必要性，host和controller之間直接通過api來互動。像nordic的藍芽協議棧softdevice，就是採用這種模式。當然zephyr也支援這種架構。
還有一些藍芽裝置功能比較強大，它需要一顆功能非常強大的mcu來做主應用，而藍芽soc只是整個系統的一部分，這種情況下，大部分藍芽協議棧功能或者整個藍芽協議棧功能都是跑在藍芽soc中，而藍芽應用則跑在主mcu中，主mcu和藍芽soc之間的通訊協議由廠商自己定義，因此稱為自定義雙晶元架構方案。這種方案也非常常見，可以說，除了架構1和架構2之外的架構，都可以稱為架構3。架構3裡面有一種非常特殊的情況，即主mcu和藍芽soc之間採用了hci介面進行通訊，由於這裡的hci只是用來進行物理通訊，而通訊的主體不是host和controller，通訊包應用資料也不遵循藍芽核心規格規範，因此不能把它看成第1種架構，nordic的serialization方案就屬於這種特殊情況。
三種藍芽架構實現方案（藍芽協議棧方案）
藍芽架構實現方案有哪幾種？我們一般把整個藍芽實現方案叫做藍芽協議棧，因此這個問題也可以這麼闡述 藍芽協議棧有哪些具體的架構方案？在藍芽協議棧中，host是什麼？controller是什麼？hci又是什麼？大家都知道，不同的應用場景有不同的需求，因此不同的應用場景對藍芽實現方案的要求也不一樣，從而催生...
藍芽裝置開發的三種方式
藍芽裝置開發一般包含藍芽晶元及主機的開發。主機部分根據應用情況可以是pc，微控制器，arm等。藍芽通訊協議是一組協議的集合，從最底層的硬體驅動，到上層的通訊協議，都由明確的規定。藍芽裝置必須實現這些協議組，才能與其他標準藍芽裝置進行無縫通訊。對於中上層的協議，既可以由主機實現，也可以在藍芽晶元上實現...
藍芽 BLE 三種 UUID 格式轉換
藍芽廣播中對服務 uuid 格式定義都有三種 16 bit uuid 32 bit uuid 128 bit uuid。但是熟悉安卓開發的小夥伴都知道介面都 uuid 格式，fromstring 時候 16bit 的 uuid 該咋辦呢？16bit 和 32bit 的 uuid 與 128bit 的...