在ble協議棧的層模型中，位於下部的物理層、鏈路層、dtm屬於控制器，位於上部的l2cap、att、gatt、gap、sm層則屬於主機，在主機之上使用者自己的程式稱為使用者程式。因此ble協議棧進一步可以抽象為三層：控制器、主機和使用者程式。
ble協議棧規劃的晶元實現方案有單晶元方案，雙晶元方案和三晶元方案。
單晶元方案即主機和控制器在同一顆晶元內，雙晶元方案是主機和控制器分屬兩顆不同晶元，三晶元方案則是將使用者程式也放在單獨晶元內。單晶元放置協議棧全部內容，勢必需要巨大flash和sram，而早期主流的晶元資源可能並沒有那麼充裕，因而提出雙晶元方案。
我們知道，ble協議誕生於2023年推出的bluetooth 4.0，當時arm已經大行其道，說晶元沒有資源是站不住腳的，但是為什麼還是有這個雙晶元方案的考慮呢？這需要用歷史的眼光去看到ble協議。ble脫胎於藍芽協議，在許多方面借鑑和整合了經典藍芽的既有特徵，在追求低功耗這個目標的路上，也盡量保持藍芽協議棧核心架構的原始面貌。而經典藍芽由來已久，所以我們可以猜測，這樣的雙晶元方案甚至三晶元方案的設計是從經典藍芽那邊繼承過來的特性。
就單晶元而言，hci主要有兩個用途。
乙個是保持對ble協議棧的相容性，既然spec這樣定義，那麼協議棧ip**商也就這麼實現。另乙個是用於ble的rf測試。面向ble的rf測試的裝置，都會配備乙個uart介面用於資料通訊，而hci在外部就表現為乙個uart介面，這樣在測試時，直接用uart線連線測試裝置與晶元的uart管腳即可。軟體層面，ble spec提供一套hci指令，測試裝置自動收發處理，無需人工干預。結合上一期介紹的dtm層，我們可以簡單理解，dtm和hci就是為ble的rf測試而存在的。dtm定義了測試內容和格式，hci提供通訊介面
假如安裝了cypress kit 042-ble的幫助檔案，可以在安裝目錄下找到dtm的示例工程：psoc_ble_dtm。該工程演示了如何使用dtm和hci進行ble測試。
很遺憾，該工程過於簡單，導致使用者一臉懵懂，不知示例為何。其實正如前面所說，rf測試裝置通常已經配備了自動傳送命令，處理資料的能力，因此只要將ble配置為dtm模式，並且指定hci串列埠管腳即可，無需其他額外操作，所以我們看到工程的main檔案中未新增任何操作**。
BLE協議棧 介紹
ble協議棧的官方文件 這些網路資源對於協議棧的細節大多點到為止，無以深入，於是我嘗試結合自己的經驗，挑重點介紹一下ble協議棧的內容。成文過程主要參考 ble權威指南 一書，也利用google baidu做了大量搜尋，借鑑了許多第三方部落格和論壇的優質答案並保留了原始鏈結，盡可能將一些問題解釋清楚...
BLE藍芽協議 BLE連線建立過程梳理（一）
應付比廣播更為複雜的資料傳輸，或者要在裝置之間實現可靠的資料交付，這些都要依賴於連線。連線使用資料通道在兩個裝置之間可靠地傳送資訊。它採取了自適應跳頻增強魯棒性，同時使用了非常低的占空比，盡可能地降低功率消耗。裝置建立連線的過程如下圖所示。簡言之，裝置首先廣播可連線廣播事件，其他裝置收到之後即可發起...
BLE協議架構概述（1）
控制器controller controller實現射頻相關的模擬和數字部分，完成最基本的資料傳送和接收，controller對外介面是天線，對內介面是主機控制器介面hci host controller inte ce 控制器包含物理層phy physical layer 鏈路層ll linker...