【BLE】TI CC2640R2F SDK結構以及一些概念解析
一、概述
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環境中完成高效執行、相互通訊和資源共享。