一、概述
CC2640R2F作為BLE單SOC解決方案, TI的SDK将工程分為應用程式(APP)和協定棧(Stack)兩部分

二、協定棧
協定棧包括:主機(Host)和控制器(Controller),如下圖所示
主機通常是一個軟體棧,管理兩台或多台裝置間如何通信以及如何利用無線電同時提供幾種不同的服務。
控制器通常是一個實體裝置,它能夠發送和接收無線電信号,并将這些信号翻譯成攜帶資訊的資料包。
Controller(控制器)
1、PHY(實體層Physical Layer)
采用2.4GHz無線電,完成電磁的傳輸和接收工作,無線電波通常可以在給定的某個頻段内通過改變幅度、頻率或相位攜帶資訊,在低功耗藍牙中,采用一種稱為高斯頻移鍵控(GFSK)的調制方式改變無線電波的頻率,傳輸0或1的資訊。
2、LL(鍊路層Link Layer)
負責發廣播、掃描、建立連接配接以及確定資料包按照正确的方式組織、正确地計算檢驗值和加密序列等,簡單來說就是負責兩個BLE裝置之間的發現、連接配接以及資料互動,并将資料按照一定的格式打包成封包再通過實體層進行操作。為實作廣播、連接配接以及資料的傳輸,LL信道(簡單了解為通信頻道)分為廣播信道(3個)和資料信道(37個)總計40個信道。其中廣播信道固定為37、38、39,其餘的均為資料信道。
3、HCI(主機-控制器接口Host-Controller Interface)
顧名思義,HCI提供主機和控制器的通信接口,它允許主機将指令和資料發送到控制器,并且允許控制器将事件和資料發送到主機。
藍牙規範定義了4種實體接口:UART、3線UART、USB、SDIO,應用于系統中主機和控制器分别位于2個晶片上的情況。對于CC2640R2F這種單晶片裝置,HCI展現為邏輯接口。
Host(主機)
1、L2CAP(邏輯鍊路控制和适配協定)
低功耗藍牙的複用層,具有協定複用、分段重組、服務品質quality of service資訊的交換、組抽象的功能。例如連接配接參數更新請求和響應就在這裡實作。其定義了2個基本概念:L2CAP信道和L2CAP信令。對于BLE,有3條固定的信道
2、SM(安全管理器 Security Manager)
安全管理器定義了一個簡單的配對和密鑰分發協定,配對是一個擷取對方裝置信任的過程,通常采取認證的方式實作。
3、ATT(屬性協定Attribute Protocol)
它由6種基本操作構成:請求、響應、指令、訓示、确認、通知。定義了用戶端與服務端如何互相發送符合标準的消息。
4、GATT(通用屬性規範Generic Attribute Profile)
定義了用戶端與服務端如何發現與使用服務、特性與描述符的标準方法。分為3種基本類型:發現規程、用戶端發起規程、服務端發起規程。另外的交換MTU規程屬于屬性協定中的MTU交換請求。
發現規程:
4種需要發現的基本對象:首要服務、次要服務以及該服務執行個體所公開的特性和描述符。
發現服務:
有3種發現服務的途徑:發現所有首要服務、按服務UUID發現首要服務、查找包含服務。
特性發現:
在服務被發現後,便可以發現每一個服務的特性,要擷取完整的特性,需要發現特性和特性描述符。
用戶端發起規程:
對于特性,用戶端可執行:讀取特性值、寫入特性值、讀取特性描述符、寫入特性描述符。
服務端發起規程:
有2種GATT規程是由服務端發起的:通知(Notify)、訓示(Indicate),其中
通知是服務端任何時刻都可以發送給用戶端,而不需要用戶端的确認便可以發送下一條消息。
訓示是服務端任何時刻都可以發送給用戶端,在進行下一次發送前服務端必須已經确認上一條消息被用戶端接收到了。
5、GAP(通用通路規範Generic Access Profile)
定義了裝置如何彼此發現、建立連接配接以及如何實作綁定,同時描述了裝置如何成為廣播者和觀察者,并且實作無需連接配接的資料傳輸。
BLE定義了4類GAP角色:廣播者、觀察者、外圍裝置、中央裝置。
三、應用程式
應用程式包括:使用者的application、GAP角色設定、profile規範配置檔案。
在這一層,我們根據實際需求将晶片設定為對應的角色(外圍裝置、中央裝置),這一過程在GAP實作。
Profile包含了service(服務) 、characteristic(特性)
1、profile
profile可以了解為一種規範,一個标準的通信協定,它通常存在于從機中。藍牙組織規定了一些标準的profile,例如 HID OVER GATT ,防丢器 ,心率計等。每個profile中會包含多個service,每個service代表從機的一種能力。
2、service
service可以了解為一個服務,在ble從機中,通過有多個服務,例如電量資訊服務、系統資訊服務等,每個service中又包含多個characteristic特征值。每個具體的characteristic特征值才是ble通信的主題。比如目前的電量是80%,是以會通過電量的characteristic特征值存在從機的profile裡,這樣主機就可以通過這個characteristic來讀取80%這個資料
3、characteristic
characteristic特征值,ble主從機的通信均是通過characteristic來實作,可以了解為一個标簽,通過這個标簽可以擷取或者寫入想要的内容。
4、UUID
UUID,統一識别碼,我們剛才提到的service和characteristic,都需要一個唯一的uuid來辨別。藍牙聯盟已經定義了許多标準的UUID,見部落格,使用者也可以自行定義的UUID格式,那麼便隻能被自己所了解而無法被采用UUID标準的裝置所了解(會顯示Unknow)
每個從機應用中都會有一個Profile的存在,Profile包含service, 使用者可自行添加service,每個service又包含了多個characteristic,主機和從機之間的通信,均是通過characteristic來實作,即通信資料都存放于characteristic中。
四 、ICall
SDK将工程劃分為2個工程(APP和Stack)進行管理,那麼APP和Stack之間的通信便無法像正常API調用和全局變量方式進行消息傳遞,這時候便引入ICall(消息架構) 基于TI-RTOS提供服務(例如,同步線程、消息、事件)完成BLE協定棧和應用程式在兩個工程的消息互動,保證了應用程式和協定棧在統一的TI-RTOS環境中完成高效運作、互相通信和資源共享。