蓝牙BLE(协议栈、OSAL、蓝牙APP工具)
目錄
- 藍(lán)牙配對(duì)和綁定
- 藍(lán)牙4.0 BLE
- 信道(RF Channel)
- BLE協(xié)議棧分層
- PHY層(Physical layer 物理層)
- LL層(Link Layer 鏈路層)
- HCI層(Host controller interface 主機(jī)控制接口層)
- L2CAP層(Logic link control and adaptation protocol 邏輯鏈路控制和自適應(yīng)協(xié)議)
- SMP層(Secure manager protocol 安全管理協(xié)議)
- GAP層(Generic access profile 通用訪問(wèn)配置文件) —— 用于連接
- GAP 狀態(tài)(待機(jī)、廣播、掃描、連接、主從)
- BLE 連接請(qǐng)求參數(shù)(連接間隔、廣播間隔、從機(jī)潛伏、監(jiān)督超時(shí))
- GAP Role Task(參數(shù)配置api、廣播內(nèi)容、連接間隔、斷開藍(lán)牙、更新參數(shù))
- GAP Bond Manager(GAP Bond Mgr 連接安全初始化api)
- ATT(Attribute protocol 屬性協(xié)議層)
- GATT(Service/Characteristic的UUID主從機(jī)通信) —— 用于通信
- 頂層profile配置文件
- Lib 庫(kù)文件
- 外設(shè)驅(qū)動(dòng)
- 藍(lán)牙主機(jī)和從機(jī)之間傳輸數(shù)據(jù)實(shí)現(xiàn)
- 一款強(qiáng)大的芯片nRF52840及利用藍(lán)牙5.0實(shí)現(xiàn)數(shù)據(jù)遠(yuǎn)程采集
- BLE開發(fā)環(huán)境搭建
- OSAL工作原理
- TASK初始化(osal_start_system調(diào)用初始化函數(shù)osalInitTasks)
- TASK與event 處理(osal_start_system調(diào)用運(yùn)行函數(shù)osal_run_system)
- OSAL函數(shù)api介紹
- OSAL 添加事件函數(shù)
- OSAL內(nèi)存管理函數(shù)
- OSAL消息通信函數(shù)
- 其他的OSAL層API函數(shù)接口
- OSAL UART實(shí)驗(yàn)
- OSAL 主從機(jī)通信實(shí)驗(yàn)(添加特征值)
- 實(shí)驗(yàn)現(xiàn)象
- 從機(jī)上電如何實(shí)現(xiàn)廣播
- 主機(jī)自動(dòng)掃描
- 主機(jī)連接設(shè)備
- 從機(jī)串口的數(shù)據(jù)處理
- 從機(jī)藍(lán)牙讀屬性的數(shù)據(jù)處理
- 主機(jī)串口數(shù)據(jù)處理
- OSAL BLE獲得多個(gè)特征值句柄實(shí)驗(yàn)
- OSAL BLE自動(dòng)重連設(shè)備實(shí)驗(yàn)
- OSAL BLE的綁定和配對(duì)實(shí)驗(yàn)
- 藍(lán)牙協(xié)議棧遇到的問(wèn)題總結(jié)(主從模式、MAC地址、RSSI)
- IOS藍(lán)牙iBeacon協(xié)議(UUID、Major、Minor、RSSI)
- 手機(jī)藍(lán)牙APP工具的使用(nrf Connect)
- JDY-10M藍(lán)牙模塊使用教程（AT指令）
參考：芯海廠家《CST92F25 SDK開發(fā)指南V1.2.pdf》 藍(lán)牙BLE 5.0
參考：「物聯(lián)網(wǎng)」- 藍(lán)牙4.0 BLE開發(fā)入門到精通(視頻使用CC2540藍(lán)牙BLE芯片、介紹IAR編程環(huán)境安裝及使用)
地址： https://www.bilibili.com/video/BV1qZ4y1W7dz?p=3&spm_id_from=pageDriver
配套書籍：《藍(lán)牙4.0BLE開發(fā)完全手冊(cè)》 物聯(lián)網(wǎng)開發(fā)技術(shù)實(shí)戰(zhàn) 280頁(yè) 31.5M 高清書簽版
參考：BLE協(xié)議棧入門一（基本概念）
參考：淺談BLE協(xié)議棧
參考：BLE協(xié)議棧詳解
藍(lán)牙配對(duì)和綁定
https://www.cnblogs.com/iini/p/12801242.html
藍(lán)牙4.0 BLE
BLE全稱Bluetooth Low Energy，低功耗藍(lán)牙，是一種無(wú)線傳輸小數(shù)據(jù)的超低功耗藍(lán)牙技術(shù)。藍(lán)牙設(shè)備總共分為三種：Bluetooth、Bluetooth smart、Bluetooth smart ready。
- Bluetooth設(shè)備是經(jīng)典藍(lán)牙設(shè)備（比如藍(lán)牙耳機(jī)），包括BR/EDR/AMP三種技術(shù)；
- Bluetooth smart是BLE設(shè)備（比如藍(lán)牙溫度計(jì)），即低功耗藍(lán)牙設(shè)備；
- Bluetooth smart ready是雙模藍(lán)牙設(shè)備（比如手機(jī)），即同時(shí)支持傳統(tǒng)藍(lán)牙和低功耗藍(lán)牙。
這三種設(shè)備的區(qū)別和聯(lián)系如下圖(箭頭表示可以連接)：
新藍(lán)牙技術(shù)標(biāo)準(zhǔn)推動(dòng)了IPv6協(xié)議引入藍(lán)牙標(biāo)準(zhǔn)的進(jìn)程，藍(lán)牙4.2標(biāo)準(zhǔn)設(shè)備可以直接通過(guò)IPv6和6LoWPAN接入互聯(lián)網(wǎng)。
既然是無(wú)線芯片呢，其組成由軟件和硬件構(gòu)成。
- 軟件部分，為 BLE 協(xié)議棧
- 硬件部分包含 RF PHY（無(wú)線收發(fā)裝置），Modem（調(diào)制解調(diào)器），以及 Baseband（基帶）構(gòu)成。
BLE 的協(xié)議規(guī)范，全部需要遵循 Core Spec 來(lái)進(jìn)行定制，Core Spec 中包含了 RF 、Modem、Air Interface，數(shù)據(jù)編碼/解碼，以及軟件的協(xié)議規(guī)范
信道(RF Channel)
摘自：BLE（2）——基本特性（狀態(tài)、角色、地址、信道）
藍(lán)牙 BLE 工作在 2.4GHz 的頻段上，分為 40 個(gè) RF 信道，每個(gè)信道 2M。同一時(shí)刻，只能用一個(gè)信道進(jìn)行數(shù)據(jù)的傳輸/接收。
這 40 個(gè) RF Channel 上，并不是平等的， SIG 把物理信道轉(zhuǎn)換成為一個(gè)叫做 Channel Index 的玩意（其實(shí)就是簡(jiǎn)單的轉(zhuǎn)換關(guān)系）：
物理信道從 0 - 39 進(jìn)行編號(hào)。Index廣播信道：PHY Ch0 對(duì)應(yīng) 37，PHY Ch12 對(duì)應(yīng) 38，PHY 39 對(duì)應(yīng) 39。
在 BLE 4.2 時(shí)代，Advertising、Scanning、Initiating 狀態(tài)只允許在 Ch Index 的 37/38/39 上執(zhí)行數(shù)據(jù)的收發(fā)。Advertising 是為了讓其他 BLE 設(shè)備發(fā)現(xiàn)本設(shè)備，Scanning 是為了掃描到其他設(shè)備。為了讓發(fā)現(xiàn)設(shè)備和廣播更容易不受諸如 WIFI 的干擾，專門將 Advertising、Scanning、Initiating 數(shù)據(jù)收發(fā)放到了 與 WIFI 頻段隔離的部分，起到一定抗干擾作用：
除了 37、38、39 這些頻段，在 Connection 狀態(tài)下使用了 其他的 37 個(gè) Channel通信信道，通過(guò)跳頻技術(shù)（Hopping），來(lái)減少數(shù)據(jù)干擾，增強(qiáng)系統(tǒng)的可靠性。
BLE協(xié)議棧分層
- 協(xié)議：類似語(yǔ)言，如漢語(yǔ)、英語(yǔ)等。所謂協(xié)議，即將指定的字節(jié)按照一定的順序排列起來(lái)，以便他人使用自己的設(shè)備時(shí)，能通過(guò)該協(xié)議同其他設(shè)備進(jìn)行通信。協(xié)議的特點(diǎn)，就是有固定的幀格式，通過(guò)該格式發(fā)送，接收者通過(guò)解讀幀格式，進(jìn)而得到新息內(nèi)容；
- 協(xié)議棧：協(xié)議的具體實(shí)現(xiàn)形式，通俗可理解為代碼的實(shí)現(xiàn)、函數(shù)庫(kù)，供開發(fā)人員調(diào)用；
- BLE協(xié)議棧：將藍(lán)牙各個(gè)層的協(xié)議集合在一起，以函數(shù)庫(kù)的形式體現(xiàn)，并提供應(yīng)用層的API供用戶調(diào)用。
下圖是協(xié)議棧的結(jié)構(gòu)分層：
藍(lán)牙協(xié)議分host和controller兩個(gè)部分，Host是正真意義的藍(lán)牙協(xié)議，Controller為藍(lán)牙底層，或者說(shuō)是基帶芯片。
Profiles(配置文件)和應(yīng)用總是基于GAP和GATT 之上。
在單芯片方案中，Controller 和HOST、Profiles、應(yīng)用層都在同一個(gè)芯片上。
視頻中介紹的CC2540藍(lán)牙BLE SOC芯片可單芯片實(shí)現(xiàn)協(xié)議棧結(jié)構(gòu)的所有組件，開發(fā)者可以直接搭建自己的應(yīng)用程序。
PHY層(Physical layer 物理層)
PHY層用來(lái)指定BLE所用的無(wú)線頻段(2.4G)，調(diào)制解調(diào)方式和方法、跳頻等。PHY層做得好不好，直接決定整個(gè)BLE芯片的功耗，靈敏度以及selectivity等射頻指標(biāo)。
LL層(Link Layer 鏈路層)
主要是RF射頻控制，鏈路層定義了協(xié)議棧中最為基礎(chǔ)的狀態(tài)機(jī)、數(shù)據(jù)包格式、廣播和連接流程等問(wèn)題
LL層是整個(gè)BLE協(xié)議棧的核心，也是BLE協(xié)議棧的難點(diǎn)和重點(diǎn)。像Nordic的BLE協(xié)議棧能同時(shí)支持20個(gè)link（連接），就是LL層的功勞。
LL層要做的事情非常多，比如具體選擇哪個(gè)RF射頻通道進(jìn)行通信，怎么識(shí)別空中數(shù)據(jù)包，具體在哪個(gè)時(shí)間點(diǎn)把數(shù)據(jù)包發(fā)送出去，怎么保證數(shù)據(jù)的完整性，ACK如何接收，如何進(jìn)行重傳，以及如何對(duì)鏈路進(jìn)行管理和控制等等。LL層只負(fù)責(zé)把數(shù)據(jù)發(fā)送出去或者接收回來(lái)，對(duì)數(shù)據(jù)進(jìn)行怎樣的解析則交給上面的GAP或者GATT。
LL層的五種RF射頻狀態(tài)：
- Standby 待機(jī)狀態(tài)
- Advertising 廣播狀態(tài)
- Scaning 掃描狀態(tài)
- Initiating 發(fā)起連接狀態(tài)
- Connected 連接狀態(tài)
（1）Advertising、Scaning
廣播狀態(tài)下還沒(méi)有任何連接，廣播者只是單純地往外廣播數(shù)據(jù)。
掃描狀態(tài)下，掃描者僅僅接收廣播者廣播的數(shù)據(jù)。
（2）Initiating 、Connected
發(fā)起連接狀態(tài)是發(fā)起者發(fā)起的，發(fā)起者是通過(guò)發(fā)出request連接請(qǐng)求來(lái)響應(yīng)廣播者的一個(gè)設(shè)備，如果廣播者接受了這個(gè)request則進(jìn)行連接，進(jìn)入Connected連接狀態(tài)。
進(jìn)入連接狀態(tài)之后，發(fā)起連接的設(shè)備成為主設(shè)備，接受連接的設(shè)備成為從設(shè)備。
HCI層(Host controller interface 主機(jī)控制接口層)
HCI 層通信層，host 和 controller 提供一個(gè)標(biāo)準(zhǔn)化的傳輸接口。該層可以由軟件api 實(shí)現(xiàn)或者使用硬件接口 uart、spi、usb 來(lái)控制。
HCI是可選的（具體請(qǐng)參考文章： 三種藍(lán)牙架構(gòu)實(shí)現(xiàn)方案（藍(lán)牙協(xié)議棧方 案）），HCI主要用于2顆芯片實(shí)現(xiàn)BLE協(xié)議棧的場(chǎng)合，用來(lái)規(guī)范兩者之間的通信協(xié)議和通信命令等。
L2CAP層(Logic link control and adaptation protocol 邏輯鏈路控制和自適應(yīng)協(xié)議)
L2CAP 為上層提供數(shù)據(jù)封裝服務(wù)。層相當(dāng)于快遞，將數(shù)據(jù)打包，可以讓客戶點(diǎn)對(duì)點(diǎn)的通信(允許點(diǎn)對(duì)多點(diǎn))。
L2CAP對(duì)LL進(jìn)行了一次簡(jiǎn)單封裝，LL只關(guān)心傳輸?shù)臄?shù)據(jù)本身，L2CAP就要區(qū)分是加密通道還是普通通道，同時(shí)還要對(duì)連接間隔進(jìn)行管理。
L2CAP 是BLE 藍(lán)牙的復(fù)用層，其支持?jǐn)?shù)據(jù)的分割和重組，使得較大的報(bào)文可以在底層無(wú)線電中進(jìn)行傳輸。L2CAP 決定了MTU size(Maximum Transmission Unit：最大傳輸單元)，目前芯片支持的MTU_SIZE 為23~247 Bytes。
SMP層(Secure manager protocol 安全管理協(xié)議)
SM 層安全服務(wù)層，提供配對(duì)和密鑰的分發(fā)，實(shí)現(xiàn)安全連接和數(shù)據(jù)交換。
SMP用來(lái)管理BLE連接的加密和安全的，如何保證連接的安全性，同時(shí)不影響用戶的體驗(yàn)，這些都是SMP要考慮的工作。
GAP層(Generic access profile 通用訪問(wèn)配置文件) —— 用于連接
直接與應(yīng)用程序、profile配置文件進(jìn)行通信的接口，處理設(shè)備發(fā)現(xiàn)和連接等相關(guān)服務(wù)就是通過(guò)這一層。另外還處理安全特性的初始化，對(duì)上級(jí)提供應(yīng)用接口，對(duì)下層進(jìn)行配置。
GAP是對(duì)LL層payload（有效數(shù)據(jù)包）如何進(jìn)行解析的兩種方式中的一種，而且是最簡(jiǎn)單的那一種。
GAP簡(jiǎn)單的對(duì)LL payload進(jìn)行一些規(guī)范和定義，因此GAP能實(shí)現(xiàn)的功能極其有限。GAP目前主要用來(lái)進(jìn)行廣播，掃描和發(fā)起連接等，控制LL層的五種RF狀態(tài)切換。
BLE協(xié)議棧GAP層實(shí)現(xiàn)了藍(lán)牙連接功能，其定義了設(shè)備的訪問(wèn)模式與流程，包括：設(shè)備發(fā)現(xiàn)，建立連接，斷開連接，初始化安全特性，設(shè)備配置等。
GAP 狀態(tài)(待機(jī)、廣播、掃描、連接、主從)
GAP 層的藍(lán)牙狀態(tài)切換圖如圖5.3所示，每個(gè)狀態(tài)描述如下：
- 1）待機(jī)狀態(tài)(Standby)
設(shè)備沒(méi)有傳輸和發(fā)送數(shù)據(jù)，并且沒(méi)有連接到任何設(shè)備 - 2）廣播狀態(tài)(Advertiser)
周期性廣播狀態(tài) - 3）掃描狀態(tài)(Scanner)
主動(dòng)地尋找正在廣播的設(shè)備 - 4）發(fā)起連接狀態(tài)(Initiator)
主動(dòng)向某個(gè)設(shè)備發(fā)起連接 - 5）已連接，主機(jī)狀態(tài)(Master)
- 6）已連接，從機(jī)狀態(tài)(Slave)
BLE 連接請(qǐng)求參數(shù)(連接間隔、廣播間隔、從機(jī)潛伏、監(jiān)督超時(shí))
BLE 連接參數(shù)包含如下：
1）連接時(shí)間間隔：
在藍(lán)牙通信過(guò)程中，所有的數(shù)據(jù)傳輸均發(fā)生在連接事件(connection interval)期間。連接事件周期性的發(fā)生，兩個(gè)連接事件間的間隔時(shí)間即為連接間隔。每個(gè)連接事件內(nèi)可傳輸多個(gè)包，該芯片支持的最大傳輸包數(shù)量為8 個(gè)。
連接間隔示意圖如圖5.4所示。連接間隔單位時(shí)間為1.25ms，時(shí)間范圍為7.5ms~4.0s 之間。
2）從機(jī)潛伏：
當(dāng)Slave 沒(méi)有數(shù)據(jù)發(fā)送時(shí)，允許Slave 跳過(guò)連接事件。從機(jī)潛伏值(Latency)，是允許從設(shè)備跳過(guò)的最大連接次數(shù)。在連接事件中，如果Slave 沒(méi)有對(duì)Master 的包做出回應(yīng)，Master 將會(huì)在后來(lái)的連接事件中重復(fù)發(fā)送，直到Slave 回應(yīng)。圖5.5 為L(zhǎng)atency=0 與Latency=3 的對(duì)比示意圖。
3）監(jiān)督超時(shí)：
在每個(gè)連接事件中，主機(jī)發(fā)送信號(hào)，從機(jī)進(jìn)行回應(yīng)。當(dāng)長(zhǎng)時(shí)間未收到對(duì)方信號(hào)包時(shí)，藍(lán)牙將斷開，超時(shí)斷開的時(shí)間即為監(jiān)督超時(shí)時(shí)間。監(jiān)督超時(shí)時(shí)間單位為10ms，范圍為100ms~32s 之間。
連接參數(shù)由主機(jī)進(jìn)行維護(hù)與更新，從機(jī)無(wú)法更改連接參數(shù)，但是從機(jī)可以請(qǐng)求主機(jī)進(jìn)行連接參數(shù)更新。從機(jī)將連接參數(shù)期望值發(fā)送給主機(jī)，主機(jī)根據(jù)自身情況，選擇一個(gè)合適的連接參數(shù)更新或者拒絕更新。
4）BLE 廣播間隔
當(dāng)設(shè)備處于廣播狀態(tài)時(shí)，將發(fā)送廣播信號(hào)。廣播信號(hào)發(fā)生于廣播事件中，相鄰兩個(gè)廣播事件的間隔即為廣播間隔。在每次廣播事件中，廣播包會(huì)分別在3 個(gè)廣播通道（37、38、39 信道）中被發(fā)送一次。
廣播事件如圖5.6 所示。廣播間隔單位時(shí)間為0.625ms，范圍為20ms~10.24s。
GAP Role Task(參數(shù)配置api、廣播內(nèi)容、連接間隔、斷開藍(lán)牙、更新參數(shù))
GAP Role 為一個(gè)單獨(dú)的任務(wù)，其主要實(shí)現(xiàn)GAP 參數(shù)的配置，例如廣播內(nèi)容、連接參數(shù)更新參數(shù)等。
GAP 層的角色包含如下：
- 1）Broadcaster：廣播者，發(fā)射不可連接廣播信號(hào)
- 2）Observer：觀察者，進(jìn)行廣播信號(hào)掃描，但不發(fā)起連接
- 3）Peripheral：發(fā)射可連接廣播信號(hào)，并能夠被主機(jī)連接
- 4）Central：掃描廣播信號(hào)并發(fā)起連接。
常用的API 函數(shù)包含如下：
1）獲取參數(shù)
2）設(shè)置參數(shù)
3）主動(dòng)斷開藍(lán)牙
4）發(fā)送更新連接參數(shù)請(qǐng)求
GAP Bond Manager(GAP Bond Mgr 連接安全初始化api)
視頻里講的GAP security profiles
GAPBondMgr 用于藍(lán)牙連接時(shí)安全特性的初始化。藍(lán)牙安全特性定義如表5.5 所示。
| Pairing | 配對(duì)，進(jìn)行密鑰交換的過(guò)程 |
| Encryption | 加密，配對(duì)完成后或重新建立連接后，數(shù)據(jù)將加密 |
| Authentication | 認(rèn)證，在配對(duì)過(guò)程中采用了MITM 保護(hù)（如Passcode、NFC 等） |
| Bonding | 綁定，存儲(chǔ)加密密鑰至flash 存儲(chǔ)器以便下次連接使用 |
| Authorization | 授權(quán)，除了認(rèn)證外的一種應(yīng)用層密鑰交換方式 |
| OOB | 一種MITM 認(rèn)證方式，密鑰交換不通過(guò)空中傳輸，如通過(guò)NFC、串口等傳輸 |
| MITM | Man in the Middle Protection. 在配對(duì)過(guò)程中，通過(guò)該方式實(shí)現(xiàn)了認(rèn)證過(guò)程，防止通信被監(jiān)聽 |
| Just Works | 在配對(duì)過(guò)程中，不需要MITM，實(shí)現(xiàn)了密鑰傳輸 |
在通常的帶有安全特性的連接中，首次連接步驟如下：
- 1）Pairing：配對(duì)，采用Just Works 或者M(jìn)ITM（如passcode）交換秘鑰
- 2）Encryption：使用步驟1）的秘鑰加密鏈路
- 3）Bonding：保存加密秘鑰至Flash
當(dāng)需要重新建立連接時(shí)，可使用首次連接過(guò)程中Bonding 中的加密秘鑰，對(duì)連接鏈路進(jìn)行加密。如果取消Bonding 步驟，那么每次連接均需要進(jìn)行重新配對(duì)。
配對(duì)綁定配置例程如程序清單5.5 所示。
uint32 passkey = DEFAULT_PASSCODE; uint8 pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ; uint8 mitm = TRUE; //開啟MITM 認(rèn)證加密 uint8 ioCap = GAPBOND_IO_CAP_NO_INPUT_NO_OUTPUT; uint8 bonding = TRUE; //開啟bonding GAPBondMgr_SetParameter( GAPBOND_DEFAULT_PASSCODE, sizeof ( uint32 ), &passkey ); GAPBondMgr_SetParameter( GAPBOND_PAIRING_MODE, sizeof ( uint8 ), &pairMode ); GAPBondMgr_SetParameter( GAPBOND_MITM_PROTECTION, sizeof ( uint8 ), &mitm ); GAPBondMgr_SetParameter( GAPBOND_IO_CAPABILITIES, sizeof ( uint8 ), &ioCap ); GAPBondMgr_SetParameter( GAPBOND_BONDING_ENABLED, sizeof ( uint8 ), &bonding );ATT(Attribute protocol 屬性協(xié)議層)
簡(jiǎn)單來(lái)說(shuō)，ATT層用來(lái)定義用戶命令及命令操作的數(shù)據(jù)，比如讀取某個(gè)數(shù)據(jù)或者寫某個(gè)數(shù)據(jù)。BLE協(xié)議棧中，開發(fā)者接觸最多的就是ATT。
ATT 層 ATT 環(huán)境中，允許設(shè)備向另外一個(gè)設(shè)備展示一塊特定的數(shù)據(jù)，稱之為“屬性” ，展示“屬性”的設(shè)備稱為服務(wù)器，與之配對(duì)的設(shè)備稱為客戶端。
鏈路層LL狀態(tài)（主機(jī)和從機(jī)）與設(shè)備的 ATT 角色（服務(wù)器和客戶端）是相互獨(dú)立的，鏈路層的主機(jī)設(shè)備可以是 ATT 服務(wù)器，也可以是 ATT客戶端，從機(jī)也一樣。
BLE引入了attribute概念，用來(lái)描述一條一條的數(shù)據(jù)。Attribute除了定義數(shù)據(jù)，同時(shí)定義該數(shù)據(jù)可以使用的ATT命令，因此這一層被稱為ATT層。
GATT(Service/Characteristic的UUID主從機(jī)通信) —— 用于通信
Generic attribute profile通用屬性配置文件
GATT 層從名字就能看出，GATT 是在 ATT 上面的一層結(jié)構(gòu)，定義了使用 ATT的服務(wù)框架，
GATT用來(lái)規(guī)范attribute中的數(shù)據(jù)內(nèi)容，并運(yùn)用group（分組）的概念對(duì)attribute進(jìn)行分類管理。沒(méi)有GATT，BLE協(xié)議棧也能跑，但互聯(lián)互通就會(huì)出問(wèn)題，也正是因?yàn)橛辛薌ATT和各種各樣的應(yīng)用profile，BLE擺脫了ZigBee等無(wú)線協(xié)議的兼容性困境，成了出貨量最大的2.4G無(wú)線通信產(chǎn)品。
BLE 協(xié)議棧GATT 層用于實(shí)現(xiàn)兩個(gè)設(shè)備間的應(yīng)用層數(shù)據(jù)通信。GATT 層采用Client/Server 架構(gòu)，客戶端（Client）通過(guò)訪問(wèn)服務(wù)器端（Server）的服務(wù)（Service）與特征（Characteristic），實(shí)現(xiàn)數(shù)據(jù)交互。
GATT 層架構(gòu)如圖5.7 所示。
關(guān)于服務(wù)與特征的描述如下：
-
用戶的應(yīng)用由一個(gè)或多個(gè)服務(wù)(Service)組成的
-
每個(gè)服務(wù)Service 包含一個(gè)或多個(gè)特征(Characteristic)
-
每個(gè)特征(Characteristic)包含一個(gè)或多個(gè)屬性(Attribute)，Attribute屬性是設(shè)備之間傳輸?shù)男畔⒌?strong>基本單元，GATT將這些基本單元組織成一塊一塊的數(shù)據(jù)，稱為Characteristic。屬性分別如下：
-
- a. Characteristic Value：特征值
-
- b. Characteristic Declaration：特征申明，描述特征的權(quán)限、類型等
-
- c. Client Characteristic Configuration：允許GATT 服務(wù)器發(fā)送notification 或indication 數(shù)據(jù)。
-
- d. Characteristic User Description：描述特征的ASCII 字符串
- Characteristic Value：特征值的數(shù)據(jù)，層層解包之后最終想要的值。
- Characteristic Declaration：特征值數(shù)據(jù)值的屬性，位置和類型。
- Client Characteristic Configuration：配置GATT服務(wù)器主動(dòng)發(fā)送出去的屬性（notified），并且期望一個(gè)回應(yīng)（indicated）。
- Characteristic User Description：描述特征值的ASCII字符串。
- Handle：屬性表中的索引，每個(gè)屬性有一個(gè)唯一的handle。
- Type：指示屬性數(shù)據(jù)表示的什么樣的內(nèi)容，被稱為UUID。有一些UUID被SIG定義，有一些自定義。
- Permission：限制GATT客戶端對(duì)屬性值的訪問(wèn)權(quán)限，注意區(qū)分和特征值數(shù)據(jù)的訪問(wèn)權(quán)限。
GATT里定了發(fā)現(xiàn)、讀取、寫入整個(gè)屬性過(guò)程，特征值、內(nèi)容配置文件都存在屬性表中，下圖是GATT某個(gè)服務(wù)的屬性表（TI為例）：
上表中，每一行就是一個(gè)屬性
第1行表示一個(gè)服務(wù)（比如溫濕度服務(wù)）的開始
第2， 3，4行是該服務(wù)的第一個(gè)Characteristic，包含了UUID、Declaration、Char Value、Description。
第5， 6，7行是該服務(wù)的第二個(gè)Characteristic。。。
特別的是第13行，作用是配置客戶端特征值，用于server主動(dòng)發(fā)送數(shù)據(jù)給client。
藍(lán)牙的應(yīng)用開發(fā)入門就是設(shè)定特征值的屬性表，然后調(diào)用API去接收發(fā)送屬性。
頂層profile配置文件
由兩個(gè)部分組成，處于協(xié)議棧的最頂層，將協(xié)議棧和應(yīng)用層緊密的連接到一起，開發(fā)者對(duì)協(xié)議棧本身底層原理不用深入理解，就可以進(jìn)行使用開發(fā)。
下面這兩個(gè)是芯海藍(lán)牙模塊開發(fā)指南的說(shuō)明
Lib 庫(kù)文件
Lib 為藍(lán)牙庫(kù)文件，大部分藍(lán)牙協(xié)議棧在MASK ROM 代碼中實(shí)現(xiàn)，少部分藍(lán)牙協(xié)議棧代碼在Lib 庫(kù)文件中。
外設(shè)驅(qū)動(dòng)
為了實(shí)現(xiàn)更好的移植性，協(xié)議棧將硬件層抽象出了一個(gè)HAL 硬件抽象層，當(dāng)新的硬件平臺(tái)做好后，只需修改HAL，而不需修改HAL 之上的協(xié)議棧的其他組件和應(yīng)用程序。
藍(lán)牙主機(jī)和從機(jī)之間傳輸數(shù)據(jù)實(shí)現(xiàn)
https://blog.csdn.net/happygrilclh/article/details/76290561
一款強(qiáng)大的芯片nRF52840及利用藍(lán)牙5.0實(shí)現(xiàn)數(shù)據(jù)遠(yuǎn)程采集
https://blog.csdn.net/daocaokafei/article/details/116949986
BLE開發(fā)環(huán)境搭建
教程使用IAR，添加BLE藍(lán)牙協(xié)議棧文件，類似操作系統(tǒng)的OSAL
OSAL工作原理
相關(guān)博文：OSAL
STM32 OSAL操作系統(tǒng)抽象層的移植
OSAL 為Operating System Abstraction Layer，即操作系統(tǒng)抽象層，支持多任務(wù)運(yùn)行，其中BLE 協(xié)議棧、配置文件以及所有的應(yīng)用程序(app)都在其上運(yùn)行。它并不是一個(gè)傳統(tǒng)意義上的操作系統(tǒng)，而是一個(gè)允許軟件建立和執(zhí)行事件的循環(huán)。OSAL 基于消息驅(qū)動(dòng)，是一個(gè)簡(jiǎn)易的任務(wù)輪詢系統(tǒng)。
OSAL層一個(gè)時(shí)間內(nèi)只有一個(gè)任務(wù)在運(yùn)行，CPU可以使用任務(wù)調(diào)度機(jī)制策略，每個(gè)任務(wù)分配一個(gè)特定的時(shí)間片，就有點(diǎn)像操作系統(tǒng)，時(shí)間片用完了就進(jìn)行任務(wù)切換，由于每個(gè)任務(wù)執(zhí)行的時(shí)間很短(OSAL每個(gè)任務(wù)可能就15ms)，任務(wù)切換的很頻繁，就看到一個(gè)假象，OSAL同時(shí)多個(gè)任務(wù)在運(yùn)行。
OSAL 與RTOS 相比，缺少了任務(wù)堆棧，系統(tǒng)延時(shí)，中斷管理，進(jìn)程間通信，保存上下文的任務(wù)調(diào)度。
軟件功能是由任務(wù)事件來(lái)實(shí)現(xiàn)的，創(chuàng)建一個(gè)任務(wù)事件需要以下工作：
- 1）創(chuàng)建任務(wù)ID（task identifier）；
- 2）編寫任務(wù)初始化（task initialization routine）進(jìn)程，并需要添加到OSAL 初始化進(jìn)程中，這就是說(shuō)系統(tǒng)啟動(dòng)后不能動(dòng)態(tài)添加任務(wù)；
- 3）編寫任務(wù)處理程序；
- 4）如有需要提供消息服務(wù)。
BLE 協(xié)議棧的各層都是以O(shè)SAL 任務(wù)方式實(shí)現(xiàn)，由于LL 控制任務(wù)的時(shí)間要求最為迫切，所以其任務(wù)優(yōu)先級(jí)最高。為了實(shí)現(xiàn)任務(wù)管理，OSAL 通過(guò)消息處理(message process)，存儲(chǔ)管理，計(jì)時(shí)器定時(shí)等附加服務(wù)實(shí)現(xiàn)。
OSAL 任務(wù)事件處理回調(diào)函數(shù)數(shù)組示例如程序清單5.1所示。任務(wù)事件處理函數(shù)xx_ProcessEvent 順序需與后續(xù)的osalInitTasks 函數(shù)內(nèi)的Task 初始化順序一致。
先建立一個(gè)事件表，保存各任務(wù)對(duì)應(yīng)的事件
再建立一個(gè)事件處理函數(shù)表，保存各任務(wù)對(duì)應(yīng)的事件處理函數(shù)
將兩個(gè)表對(duì)應(yīng)起來(lái)
事件處理函數(shù)表：
里面保存的都是函數(shù)指針
TASK初始化(osal_start_system調(diào)用初始化函數(shù)osalInitTasks)
為了使用OSAL，在main 函數(shù)的最后要啟動(dòng)一個(gè)名叫osal_start_system 的進(jìn)程，該進(jìn)程會(huì)調(diào)用由特定應(yīng)用決定的初始化函數(shù)osalInitTasks。osalInitTasks 函數(shù)示例如程序清單5.2所示。
事件表：
接上文程序 const uint8 tasksCnt = sizeof(tasksArr)/sizeof(tasksArr[0]); uint16 *tasksEvents;/** * @fn void osalInitTasks(void) * @brief This function invokes the initialization function for each task. * @param none * @return none */ void osalInitTasks( void ) {uint8 taskID = 0; tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt); //tasksEvents事件表首地址 通過(guò)這個(gè)指針可以訪問(wèn)到事件表的每一項(xiàng) //如果有事件發(fā)生，就查找函數(shù)表，找到對(duì)應(yīng)事件的處理函數(shù)進(jìn)行處理//處理完成繼續(xù)訪問(wèn)事件表，看是否還有其他事件要發(fā)生 基于事件驅(qū)動(dòng)的輪詢操作系統(tǒng)osal_memset( tasksEvents, 0, (sizeof( uint16 ) * tasksCnt));/* LL Task */ LL_Init( taskID++ );//ID越小，優(yōu)先級(jí)越高 LL控制任務(wù)的時(shí)間要求最為迫切，任務(wù)優(yōu)先級(jí)最高/* HCI Task */HCI_Init( taskID++ ); #if defined ( OSAL_CBTIMER_NUM_TASKS )/* Callback Timer Tasks */osal_CbTimerInit( taskID );taskID += OSAL_CBTIMER_NUM_TASKS; #endif/* L2CAP Task */L2CAP_Init( taskID++ );/* SM Task */SM_Init( taskID++ );/* GAP Task */GAP_Init( taskID++ );/* GATT Task */GATT_Init( taskID++ );/* Profiles */GAPRole_Init( taskID++ ); #if(DEFAULT_GAPBOND_MGR_ENABLE==1)GAPBondMgr_Init( taskID++ ); #endifGATTServApp_Init( taskID++ );/* Application */SimpleBLEPeripheral_Init( taskID );//GAP GATT的配置 視頻中串口、LED、ADC實(shí)驗(yàn)也在此函數(shù)內(nèi)完成 }osalInitTasks 函數(shù)逐個(gè)調(diào)用BLE 協(xié)議棧各層的啟動(dòng)進(jìn)程來(lái)初始化協(xié)議棧，并設(shè)置一個(gè)任務(wù)的8bit 任務(wù)ID（task ID）。osalInitTasks 函數(shù)執(zhí)行完成后，將跳入循環(huán)等待執(zhí)行任務(wù)，系統(tǒng)啟動(dòng)完成。
使用OSAL 時(shí)，注意事項(xiàng)如下：
- 1）任務(wù)優(yōu)先級(jí)決定于任務(wù)ID，任務(wù)ID 越小，優(yōu)先級(jí)越高
- 2）BLE 協(xié)議棧各層的任務(wù)優(yōu)先級(jí)比應(yīng)用程序的高。
TASK與event 處理(osal_start_system調(diào)用運(yùn)行函數(shù)osal_run_system)
OSAL 完成TASK 初始化后，將調(diào)用osal_start_system 函數(shù)開始運(yùn)行OSAL系統(tǒng)。系統(tǒng)是以一個(gè)死循環(huán)的形式工作的，其函數(shù)實(shí)現(xiàn)如程序清單5.3 所示，該代碼在MaskROM 中運(yùn)行。
void osal_start_system( void ) {for(;;) // Forever Loop{osal_run_system();} }
OSAL 任務(wù)事件采用16 位變量定義，每1 位表示1 個(gè)唯一的事件標(biāo)識(shí)，因此每個(gè)任務(wù)最多可定義16個(gè)不同類型事件。OSAL 事件處理流程圖如圖5.1所示。
osal_run_system 函數(shù)（在osal_start_system 函數(shù)的死循環(huán)內(nèi)調(diào)用）流程如下：
- 1）更新OSAL Timer，以便設(shè)置timeout 事件，同時(shí)將事件查詢task id 設(shè)置為0
- 視頻中此處Hal_ProcessPoll()，HAL層信息處理
- 2）判斷當(dāng)前task id 的任務(wù)是否有事件發(fā)生，如有跳轉(zhuǎn)至步驟3），如無(wú)則進(jìn)行task id 自增，并繼續(xù)執(zhí)行步驟2）的判斷流程。當(dāng)task id 超出任務(wù)數(shù)量時(shí)，跳轉(zhuǎn)至步驟4）
- 3）執(zhí)行tasksArr 回調(diào)函數(shù)數(shù)組內(nèi)的對(duì)應(yīng)xx_ProcessEvent 函數(shù)，執(zhí)行完成后，退出osal_run_system 函數(shù)，并在下次循環(huán)里繼續(xù)開始整個(gè)流程。
- 4）執(zhí)行Sleep 調(diào)度，當(dāng)喚醒后，繼續(xù)開始整個(gè)流程。
當(dāng)事件處理程序處理完相應(yīng)事件后，需要清除相應(yīng)標(biāo)識(shí)。如未清除相應(yīng)標(biāo)識(shí)，OSAL 會(huì)認(rèn)為事件還沒(méi)有處理完成，后續(xù)會(huì)繼續(xù)調(diào)用相應(yīng)處理函數(shù)進(jìn)行處理。
如在simpleBLEPeripheral(從機(jī)) 例程中，當(dāng)事件START_DEVICE_EVT 發(fā)生，其處理函數(shù)SimpleBLEPeripheral_ProcessEvent 就運(yùn)行，結(jié)束后返回16bit 事件變量，并清除事件標(biāo)識(shí)SBP_START_DEVICE_EVT。程序代碼如程序清單5.4 所示。
if ( events & SBP_START_DEVICE_EVT ) {……return ( events ^ SBP_START_DEVICE_EVT ); }OSAL函數(shù)api介紹
OSAL 添加事件函數(shù)
視頻課程里介紹的這些api在OSAL.c文件里面
- 1）立即事件
- 2）定時(shí)器事件
- 3）自動(dòng)加載定時(shí)器事件
OSAL內(nèi)存管理函數(shù)
視頻課程里介紹的這些api在OSAL.c文件里面
OSAL 提供了基本的內(nèi)存管理函數(shù)。內(nèi)存管理函數(shù)定義如下：
1）內(nèi)存分配
void *osal_mem_alloc( uint16 size ) 調(diào)用該函數(shù)將分配指定size 的內(nèi)存空間，并返回內(nèi)存首地址。當(dāng)分配失敗時(shí)，將返回NULL。2）內(nèi)存釋放
void osal_mem_free( void *ptr ) 調(diào)用該函數(shù)將釋放之前分配的內(nèi)存空間。OSAL消息通信函數(shù)
OSAL 消息機(jī)制實(shí)現(xiàn)了不同子系統(tǒng)之間的通信。消息即為數(shù)據(jù)，數(shù)據(jù)種類和長(zhǎng)度都不限定。消息管理函數(shù)定義如下：
- 1）OSAL 消息創(chuàng)建
- 2）OSAL 消息發(fā)送
- 3）OSAL 消息接收
- 4）OSAL 消息釋放
SYS_EVENT_MSG（0x8000）是OSAL 保留的消息處理事件，所有任務(wù)均包含該事件。該事件用于消息的傳遞，即將參數(shù)從一個(gè)任務(wù)傳遞給另一個(gè)任務(wù)，詳情請(qǐng)參考“OSAL 消息”章節(jié)。
其他的OSAL層API函數(shù)接口
OSAL API
OSAL UART實(shí)驗(yàn)
uart結(jié)構(gòu)體:
uart函數(shù)：
uart調(diào)用，290行串口輸出：Hello BLE World
串口回調(diào)函數(shù)內(nèi)容：
OSAL 主從機(jī)通信實(shí)驗(yàn)(添加特征值)
主從機(jī)通信通過(guò)特征值實(shí)現(xiàn)的，類似標(biāo)簽，有四個(gè)屬性：長(zhǎng)度、讀寫、UUID、功能。
本實(shí)驗(yàn)實(shí)現(xiàn)了R6的功能。
UUID
長(zhǎng)度
讀寫
把char6所有的屬性加入到屬性表里
set函數(shù)添加char6
get函數(shù)添加char6
Read讀取回調(diào)函數(shù)
特征值被主機(jī)讀取或被從機(jī)通知的時(shí)候，調(diào)用這個(gè)回調(diào)函數(shù)
write寫入回調(diào)函數(shù)
change回調(diào)函數(shù)
init函數(shù)設(shè)置char6屬性參數(shù)，這里才是真正把char6屬性值設(shè)置好了
這個(gè)可有可無(wú)
連接狀態(tài)改變的時(shí)候，，可有可無(wú)
實(shí)驗(yàn)現(xiàn)象
從機(jī)上電開始廣播，主機(jī)（比如手機(jī)藍(lán)牙助手）進(jìn)行通信。
視頻中又寫了一個(gè)主機(jī)的程序，雙方通過(guò)串口轉(zhuǎn)發(fā)(透?jìng)?，方便演示：
客戶端發(fā)現(xiàn)事件處理
從機(jī)上電如何實(shí)現(xiàn)廣播
在SimpleBLEPeripheral_Init函數(shù)里面，將從機(jī)廣播功能設(shè)置為TRUE
主機(jī)自動(dòng)掃描
主機(jī)連接設(shè)備
從機(jī)串口的數(shù)據(jù)處理
從機(jī)藍(lán)牙讀屬性的數(shù)據(jù)處理
主機(jī)串口數(shù)據(jù)處理
OSAL BLE獲得多個(gè)特征值句柄實(shí)驗(yàn)
主機(jī)當(dāng)客戶端代碼分析
添加特征值
修改事件函數(shù)simpleBLEGATTDiscoveryEvent
OSAL BLE自動(dòng)重連設(shè)備實(shí)驗(yàn)
默認(rèn)斷開設(shè)備主機(jī)是不能重新連接的，
OSAL BLE的綁定和配對(duì)實(shí)驗(yàn)
一般要輸入密碼，安全，限制非法連接
在SimpleBLEPeripheral_Init函數(shù)里面
改回調(diào)函數(shù)
不要每次都輸入密碼綁定
藍(lán)牙協(xié)議棧遇到的問(wèn)題總結(jié)(主從模式、MAC地址、RSSI)
參考：藍(lán)牙4.0BLE協(xié)議棧學(xué)習(xí)筆記（二）
地址：https://blog.csdn.net/u012246376/article/details/47700477?spm=1001.2014.3001.5502
在學(xué)習(xí)開發(fā)藍(lán)牙協(xié)議棧遇到的問(wèn)題總結(jié)：
1.藍(lán)牙設(shè)備號(hào)BD_ADDR就是MAC地址，不同于uuid，uuid是服務(wù)號(hào)，作為唯一標(biāo)識(shí)符。
2.scanRspData數(shù)組是掃描回應(yīng)數(shù)據(jù)數(shù)組，用戶可以自定義設(shè)備名。advertData數(shù)組是廣播數(shù)據(jù)數(shù)組，主要是包含在廣播里的數(shù)據(jù)信息。
3.主從機(jī)通信：
主從機(jī)通信具體流程就是 Scanning (搜索) -->Devices Found（發(fā)現(xiàn)從機(jī)） --> Connected (連接) --> discover Service（發(fā)現(xiàn)設(shè)備服務(wù)）–>讀寫characteristic(屬性)。
協(xié)議棧中的SimpleBLEPeripheral是從機(jī)模式，主要是廣播信息，讓其他設(shè)備知道。
SimpleBLECentral是主機(jī)模式，主要是與從機(jī)建立連接。
讀寫characteristic可以理解為GATT層的client向service發(fā)送數(shù)據(jù)，或者是service向client端發(fā)送數(shù)據(jù)。
主機(jī)設(shè)備可以是client（客戶端），也可以是service（服務(wù)器），即主機(jī)向從機(jī)發(fā)送數(shù)據(jù)，從機(jī)主動(dòng)向主機(jī)發(fā)送數(shù)據(jù)。
主機(jī)向從機(jī)讀寫數(shù)據(jù)調(diào)用GATT_WriteCharValue函數(shù)和ATT_ReadCharValue函數(shù)。如下：
if ( simpleBLEDoWrite ) {// Do a writeattWriteReq_t req;req.handle = simpleBLECharHdl+2;req.len = 2;req.value[0] = simpleBLECharVal;req.sig = 0;req.cmd = 0;status = GATT_WriteCharValue( simpleBLEConnHandle, &req, simpleBLETaskId ); if ( status == SUCCESS ) {NPI_WriteTransport(“write ok\r\n”, 10);simpleBLEProcedureInProgress = TRUE;simpleBLEDoWrite = !simpleBLEDoWrite; }else {// Do a readattReadReq_t req;req.handle = simpleBLECharHdl+2;status = GATT_ReadCharValue( simpleBLEConnHandle, &req, simpleBLETaskId ); }從機(jī)和主機(jī)發(fā)送數(shù)據(jù)機(jī)制不一樣。主機(jī)用write命令，從機(jī)用Notification通知命令。從機(jī)向主機(jī)發(fā)送數(shù)據(jù)調(diào)用GATT_Notification函數(shù)，如：
static attHandleValueNoti_t Report ; uint16 GetHandle; noti.len = 1; noti.value[0] = GetLen; GATT_Notification(GetHandle, &Report, FALSE );4.獲取電池電量：
battMeasure函數(shù)是通過(guò)ADC采集內(nèi)部電壓獲得的電壓值，參考電壓是1.25v，最大測(cè)量電壓是3.75V。如果要獲取精度較高的值需要從外部輸入引腳接入穩(wěn)定性較高的參考電壓，然后通過(guò)ADC采集轉(zhuǎn)換。
5.獲取RSSI值：
通過(guò)獲取信號(hào)強(qiáng)度RSSI值，可以測(cè)定信號(hào)源與接收點(diǎn)的距離，即標(biāo)簽和基站的距離。從而用相關(guān)算法進(jìn)行定位。注意的是由于受到脈沖干擾等會(huì)出現(xiàn)浮動(dòng)值，需要進(jìn)行濾波算法來(lái)獲得比較準(zhǔn)確的采樣值。
IOS藍(lán)牙iBeacon協(xié)議(UUID、Major、Minor、RSSI)
ibeacon和藍(lán)牙有什么區(qū)別_它們的區(qū)別在哪里
7-iBeacon參數(shù)
藍(lán)牙IBEACON協(xié)議案例詳細(xì)解析
手機(jī)藍(lán)牙APP工具的使用(nrf Connect)
摘自：nrf Connect低功耗藍(lán)牙APP工具的使用
APP下載： nRF Master Control Panel (BLE)
安卓、IOS平臺(tái)都有
該APP可以實(shí)現(xiàn)SCANER和ADVERTER兩種角色
下面主要來(lái)講講SCANER角色的使用
掃描者
點(diǎn)擊SCAN或者下拉界面，可以刷新設(shè)備列表，右滑界面可以看到每個(gè)設(shè)備的信號(hào)強(qiáng)度的變化曲線圖，不同顏色代表不同的設(shè)備。
連接設(shè)備
測(cè)試設(shè)備的設(shè)備名稱GCBT40-my，點(diǎn)擊CONNECT
連接成功后會(huì)自動(dòng)獲取所有的服務(wù)UUID
可寫與可監(jiān)聽
設(shè)備GCBT40-my發(fā)布了服務(wù)UUID=0xff10，
特征值UUID=0xff11為可寫操作（點(diǎn)擊圖標(biāo)”↑“），特征值UUID=0xff12為可監(jiān)聽操作（點(diǎn)擊圖標(biāo)”↓↓↓“），
寫操作(APP到從設(shè)備)
寫操作，數(shù)據(jù)從APP端發(fā)送到從設(shè)備端
點(diǎn)擊寫操作后，可以選擇輸入數(shù)據(jù)的格式，TEXT為字符串格式，可以先在Save as里輸入數(shù)據(jù)，再點(diǎn)SAVE保存，下次可以直接在LOAD里發(fā)送該數(shù)據(jù)包
監(jiān)聽操作(從設(shè)備到APP0)
數(shù)據(jù)從從設(shè)備端發(fā)送到APP端
點(diǎn)擊圖標(biāo)”↓↓↓“后，APP后臺(tái)自動(dòng)監(jiān)聽從設(shè)備notify上來(lái)的數(shù)據(jù)，右滑界面，可以看到接收到的每條數(shù)據(jù)
JDY-10M藍(lán)牙模塊使用教程（AT指令）
參考：千鋒嗨哥_物聯(lián)網(wǎng)_嵌入式開發(fā)與應(yīng)用教程（教程包含藍(lán)牙、4G、WIFI、NB-iot、ZigBee等）
地址：https://www.bilibili.com/video/BV1Ui4y1s71B?p=52
藍(lán)牙開發(fā)介紹
JDY-10M模塊介紹
JDY-10M引腳說(shuō)明
普通數(shù)據(jù)收發(fā)AT指令
使用AT指令，隱藏了底層的藍(lán)牙通信協(xié)議棧
控制功能數(shù)據(jù)AT指令
手機(jī)APP通信
總結(jié)
以上是生活随笔為你收集整理的蓝牙BLE(协议栈、OSAL、蓝牙APP工具)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： wps表格在拟合曲线找点_excel如何
- 下一篇： Java 默认/缺省 内存大小，如果没有