ARM平臺上藍芽協議棧Bluez的移植使用和配置
作者：劉旭暉 Raymond轉載請註明出處
主頁：http://rgbbones.googlepages.com/
Bluez作為當前最成熟的開源藍芽協議棧，在Linux的各大發行版中已經得到了廣泛的應用。在桌面環境下，使用Bluez應該已經沒有太大的問題，本文的主要目的是介紹在嵌入式平臺上，搭建和配置Bluez的各個Profile執行所需做的工作，討論可能遇到的問題，介紹一些工具的使用和工作原理。因為本人的能力和測試時間有限，可能下文中有些理解、分析不一定準確，歡迎聯絡指正。
1相關說明
1.1網站資源
Bluez的官方網址：這裡提供最新的原始碼下載，最近伺服器崩潰了一次，有些東西沒了。。。。
相關郵件列表：
1.2工作環境
個人感覺，使用Bluez最大的問題就是文件的欠缺，除了Wiki上的有限資料以外，很難找到其它有用的文件。
由於Bluez的程式碼實現更新變化得很快，網上的許多文件介紹的都是早期版本的使用，再有的文章多數是基於成熟的Linux發行版，來討論藍芽裝置的配置和使用，對於嵌入系統開發，自己編譯，搭建和配置相關環境的文章很少。此外和具體藍芽晶片相關的資料也很難找到。
這裡我不打算也沒有能力寫一個完整的指南，只能基於前段時間在自己的板子上所做的工作，總結一下相關的步驟和所遇到的各類問題以及這期間所掌握的各種相關知識。希望能給有類似開發需求的朋友一些有益的幫助，下面是這篇文章所基於的工作環境：
Ø硬體平臺：基於ARM的嵌入式板子
Ø藍芽晶片：CSR BC4 ROM 版本晶片，不帶eeprom
Ø軟體環境：Linux
ØBluez版本：bluez-libs 3.22 bluez-utils 3.22
2編譯
2.1核心
相信多數人使用的都是2.6的核心了，在2.6的核心中要支援Bluez，只要你的核心版本不是太舊，無需打Patch，直接配置好就OK了，核心裡面的程式碼相對比較穩定了。當然，Bluez對一些Bluetooth協議棧新特性的支援，還是需要更新kernel程式碼的。你應該確認你使用的kernel版本是否以及包含了對應的支援。
核心的配置，基本上把 networking下 --- Bluetooth subsystem support 裡的以下幾項全部選上即可：
L2CAP protocol support
SCO links support
RFCOMM protocol support
RFCOMM TTY support
BNEP protocol support
HIDP protocol support
此外，在Bluetooth device drivers裡選上你所需要支援的Bluetooth裝置。我使用的CSR的chip是我們直接build在板子上，通過串列埠和cpu通訊的，晶片預設使用BCSP作為通訊協議，所以我選擇了：
HCI UART driver
BCSP protocol support
如果你是通過usb介面使用藍芽介面卡，需要選擇
HCI USB driver
2.2Bluez Lib / Utils
Bluez Lib的編譯比較簡單，而Bluez-Utils所依賴的庫就比較多了，大體包括 dbus alsa hal gstreamer openobex xml等等，仔細觀察./configure 的輸出，將所需要的包先安裝或者build好。
值得注意的一點是：
如果你需要開啟所有的功能模組的支援，需要在 ./configure 引數中新增 --enable-all --enable-audio --enable-input --enable-network –enable-serial 等，在3.22版本中 --enable-all 居然不包括 audio等相關模組的service的編譯，不知道是否是因為還保留了daemon和service等不同方案的緣故。不過，這至少與他的configure --help 對於 --enable-all 的描述是不符合的。
3藍芽硬體初始化及基礎服務啟動
如果在PC環境下，使用Ubuntu，呼叫 /etc/init.d/bluetooth start 應該就能完成這一步的工作了。下面敘述一下在我的嵌入式環境下，如何手動完成這一步驟。
3.1何謂硬體初始化
硬體初始化，指的是配置藍芽晶片，將其置於一個能夠正常通訊的狀態。
對於CSR的晶片來說，就是通過設定PSKEY，設定其晶振頻率，UART波特率等等一些關鍵引數。如果使用的是USB形式的介面卡，因為其EEPROM儲存了相關的預設引數，這一步很可能不需要做，而我使用的是不帶EEPROM的ROM版本晶片，如何正確完成初始化工作著實讓我折騰了一陣。
對於其它晶片，沒有太多研究，不過，據我有限的瞭解，TI的晶片在hciattach時也需要完成一些額外的初始化工作，其它如ST的晶片則可能需要下載firmware。
3.2硬體初始化步驟
通常藍芽晶片的初始化和協議繫結可以通過 hciattach 來完成（通過配置bluez的啟動指令碼，可以不需要使用hciattach，標準發行版應該都是不用hciattach，如何配置，還沒有研究。。。 8 ）
Hciattach 需要的引數主要包括 TTY節點，裝置型別，波特率等。多數型別的裝置的初始化工作，在選擇了正確的裝置型別引數後，都由hciattach在init_uart函式中呼叫具體的初始化函式所完成。
很遺憾的是，因為要重新設定晶振頻率和波特率，並同步BCSP協議，這種方式好像處理不了我所使用的晶片（不排除我沒有找到正確的解決方案的可能性），我最終的解決辦法是在hciattach之前，使用Bluez-utils裡的BCCMD工具先完成這些PSKEY的設定工作。
具體命令是：
bccmd -t bcsp -d /dev/ttyS1 psload -r csr.psr
在這時，由於HCI介面還沒有啟動，所以只能使用BCSP協議來進行通訊，我的裝置是暴露在ttyS1下，你的可能不一樣，-r引數指明在psload完成 PSKEY的批量載入操作之後，對晶片進行Warmreset，否則這些引數的修改不會起作用。
Csr.psr的內容取決與你的晶片，我的大致如下：
// PSKEY_ANA_FREQ
&01fe =
// PSKEY_UART_BAUD_RATE
&01be = 0EBF // 921600的波特率
// PSKEY_UART_SEQ_WINSIZE
&0407 = 0006
// BDADDR
&0001 = 1122 3344 5566 7788
。。。
這裡有個問題，你會發現，通過bccmd -t bcsp psset 命令理論上應該是可以單步設定每一個PSKEY的，但是從我實踐看來，單步的操作在兩次對bccmd的呼叫過程中，上一次對PSKEY的修改，都會在下一次呼叫之前被複位，從程式碼上看估計和BCSP協議的同步過程有關。
3.2.1關於PSKEY的獲取
如何獲得正確的完整的PSKEY引數，大概會有幾個途徑：
Ø通過CSR的網站下載boot_strap包，這是CSR自己的BCHS協議棧所使用的初始化程式碼，在裡面找到你所需要的pskey值。
Ø下載CSR的bluesuite工具，裡面包含了一個叫pstool的工具，可以用它來讀寫CSR的Casira開發板或其它BT裝置的PSKEY設定，試驗並找出你能用的引數。
Ø找CSR或模組廠商支援 8 ）
不過，基本上來說，如果只是要讓晶片通過串列埠能夠和Bluez協議棧正常通訊上，只需要設定PSKEY_ANA_FREQ 和 PSKEY_UART_BAUD_RATE 這兩個PSKEY就可以了。
3.3Daemon程序的啟動
早先的版本里，Bluez的Daemon很多，但是最近的版本，很多daemon都轉為service的形式來做了，3.22 裡面包括了以下這幾個Service，其它profile貌似還保留著daemon的形式。
bluetoothd-service-serial
bluetoothd-service-network
bluetoothd-service-audio
bluetoothd-service-input
這幾個Service的啟動依賴於hcid的啟動以及相關的配置檔案
主要配置檔案位於：/etc/bluetooth/
此外，通常還需要啟動SDP來提供服務查詢，另外，Bluez本身還依賴於Dbus daemon的執行。
所以，整體上來說，我的手動啟動Bluez的全過程如下：（其中核心程式碼是以模組形式編譯的）
insmod bluetooth.ko
insmod hci_uart.ko
insmod l2cap.ko
insmod rfcomm.ko
insmod sco.ko
insmod hidp.ko
/etc/rc2.d/S20dbus start
bccmd -t bcsp -d /dev/ttyS1 psload -r csr.psr
hciattach -s 921600 /dev/ttyS1 bcsp 921600
hciconfig hci0 up
sdpd
hcid –d
4Paring配對
4.1Passkey_agent
在正常使用一個藍芽裝置前，通常都需要對該裝置進行配對繫結的操作。
Bluez的配對機制貌似也修改了幾次，2.x版本中通過pin_helper來處理pin code的應答，3.22版本里使用的配對機制，其API是基於Dbus來實現的，需要向dbus註冊一個agent，PC的發行版通常都會有一些基於各種圖形庫的passkey_agent，對於嵌入式系統，這部分程式碼可以想象，應該是要按照相應的API自己實現一個，為了測試，我直接使用了bluez-utils/daemon 目錄下的passkey-agent
這是一個命令列下的可以使用預先設定的pin code進行配對的程式
為了使用它，我的檔案系統裡 /etc/Bluetooth/hcid.conf 中 option一節類似如下：
# HCId options
options {
# Automatically initialize new devices
autoinit yes;
# Security Manager mode
#none - Security manager disabled
#auto - Use local PIN for incoming connections
#user - Always ask user for a PIN
#
security user;
# Pairing mode
pairing multi;
# Do the same as "hciconfig hci0 down" when SetMode("off")
# is called.
offmode devdown;
# Default PIN code for incoming connections
passkey "1234";
}
4.2關於自動配對和請求的發起
配對的發起，這裡主要是從請求的發起者是誰的角度來說。
通常可能不需要關心配對請求是由本地還是由遠端發起的，使用passkey_agent都能夠正確處理。
不過如果在hcid.conf中將 Security Manager mode 設定為 auto，則Bluez會將passkey後面的字串作為預設的Pin code，自動答覆遠端發起的配對請求。這是在沒有使用passkey_agent的情況下的一種配對方式。
在這種情況下，Bluez可以處理遠端的配對請求，但是對於本地發起的配對請求，將無法正確處理，我沒有仔細的分析原因，或許是程式碼特意設計成這種工作方式。所以在無法明確知道誰將會主動先發起配對請求的情況下，使用Atuo模式，可能就會出現有些時候裝置能繫結有些時候不能繫結的現象。
通常如果是由本地裝置搜尋發現的新裝置，配對繫結的操作應該也是由本地發起。
另外可以觀察到，對遠端一個非PC類的藍芽裝置，如藍芽耳機，如果上次繫結過，在耳機啟動時會主動發起連線請求，如果本地的link key丟失了，也就會再走一次繫結的流程，這種情況下配對請求就是由遠端裝置發起的。
5A2DP
A2DP藍芽立體聲應該是藍芽最常見的Profile之一。
2.x版本的Bluez，對A2DP的支援是通過
目錄(?)[-]
相關說明
網站資源
工作環境
編譯
核心
Bluez Lib / Utils
藍芽硬體初始化及基礎服務啟動
何謂硬體初始化
硬體初始化步驟
作者：劉旭暉 Raymond轉載請註明出處
主頁：http://rgbbones.googlepages.com/
Bluez作為當前最成熟的開源藍芽協議棧，在Linux的各大發行版中已
協議棧原始碼位置：external/bluetooth/bluedroid
藍芽協議棧架構：
描述了協議棧Bluedroid，HAL層藍芽適配庫以及上層應用類
模組及應用程式介面
Bluedroid 分為兩層：
- BTE: Bluetooth Embedde
在Android中，藍芽系統的結構如下圖所示：
在這個體系結構中，從下往上依次是模組驅動、藍芽協議棧、Bluetooth.apk、Framework和各種藍芽應用。其中，核心中的驅動是直接和硬體打交道的，一般由模組廠商提供。Android層中，最下面的是處
一直以來，Android對於藍芽的支援都很混亂，簡直可以說是一坨shit。各個版本的協議棧都不一樣，最早用的是bluez，進入4.x時代之後，換成了谷歌自己的bluedroid。換就換吧，至少等做完了再用吧，結果4.2、4.3、4.4的bluedroid全都不一樣。
通用屬性配置檔案（GATT）
正如GAP層負責連線相關的功能，GATT主要是負責在兩個已經連線的裝置互動資料，GAP層把BLE裝置區分為主機Master（Central）和從機Slave（Perpherial），在GATT層則區分為Server和Client。客
需要看的文件 :
《07_Simple BLE sensor application walk though.pdf》
《06_nRF51 Toolchain and Software Development kit.pdf》
《04_nRF51_seri
一、 基礎知識介紹
1.縮略語
BTIF: Bluetooth Interface
BTU : Bluetooth Upper Layer
BTM: Bluetooth Manager
BTE: Bluetooth embedded system
藍芽協議棧實現模式分析
藍芽技術是一項新興的技術。它的主要目的就是要在全世界範圍內建立一個短距離的無線通訊標準 。它使用 2.4-2.5 GHz 的 ISM（ Industrion Scientifc Medical ) 頻段來傳送話音和資料。運用成熟、實用、先進的無線
SIG在2010年釋出了4.0的specification，2013年釋出了4.1的specification，一年以後，在2014年又釋出了4.2的specification，specification的調整很快。從4.0版本起，革命性的加入了BLE協議部分，同時將2.1
原文地址：http://www.cnblogs.com/zjutlitao/p/4742428.html
宣告：這篇文章是樓主beautifulzzzz學習網上關於藍芽的相關知識的筆記，其中比較多的受益於xubin341719的藍芽系列文章，同時還有其他網上作者的資料。由於有些文章只做參
1. 前言
瞭解藍芽的人都知道，在經典藍芽中，保持連線（Connection）是一個相當消耗資源（power和頻寬）的過程。特別是當沒有資料傳輸的時候，所消耗的資源完全被浪費了。因而，對很多藍芽裝置來說（特別是功耗敏感的裝置），希望在無數可傳的時候，能夠斷開連線。但是，由於
藍芽協議分析（1）基本概念
藍芽4.1，是一個大雜燴：BR/EDR沿用舊的藍芽規範；LE抄襲802.15.4；AMP直接使用802.11。而這一切的目的，就是以相容性和易用性為基礎，在功耗和傳輸速率之間左右為難。
1.藍芽技術的概述
1.1 兩種藍芽技術：經典藍芽（檢稱 BT）
1. 前言
注1：此SM是Security Manager的縮寫，非彼SM，大家不要理解歪了！
書接上文，我們在中介紹了BLE安全機制中的終極武器----資料加密。不過使用這把武器有個前提，那就是雙方要共同擁有一個加密key（LTK，Long Term Key）。這個
簡介：
HSP（手機規格）– 提供手機（行動電話）與耳機之間通訊所需的基本功能。
HFP（擴音規格）– 在 HSP 的基礎上增加了某些擴充套件功能，原來只用於從固定車載擴音裝置來控制行動電話。
A2DP（高階音訊傳送規格）– 允許傳輸
前言 在萬物聯網的時代，安全問題將會受到非常嚴峻的挑戰（相應地，也會獲得最大的關注度），因為我們身邊的每一個IOT裝置，都是一個處於封印狀態的天眼，隨時都有被開啟的危險。想想下面的場景吧：
凌晨2點，x米手環的鬧鐘意外啟動，將你從睡夢中驚醒，然後床頭的燈光忽明忽暗……
前言 也許關注BLE的同學都注意到了，BLE裝置有多種型別的裝置地址，如Public Device Address、Random Device Address、Static Device Address、Private Device Address等等。如果不瞭解內情，大家肯定會被
前言 在上一篇文章[1]中，我們介紹了BLE的白名單機制，這是一種通過地址進行簡單的訪問控制的安全機制。同時我們也提到了，這種安全機制只防君子，不防小人，試想這樣一種場景：
A裝置表示只信任B、C、D裝置，因此就把它們的地址加入到了自己的白名單中，表示只願意和它們溝通。與此
第二章 藍芽協議規範（射頻、基帶鏈路控制、鏈路管理）
藍芽協議是藍芽裝置間交換資訊所應該遵守的規則。與開放系統互聯（OSI）模型一樣，藍芽技術的協議體系也採用了分層結構，從底層到高層形成了藍芽協議棧，各層協議定義了所完成的功能和使用資料分組格式，以保證藍芽
1 藍芽pan profile協議的概述
1.1 協議層次結構
藍芽pan就是我們熟知的藍芽網路，他在藍芽協議體系中的層次結構見如下圖：
BNEP相當於網路協議棧中的鏈路層，由該層虛擬出一個網路介面，而BNEP層以下就是藍芽核心協議之一的L2CAP。這個是在藍芽協議中的層 相關推薦
ARM平臺上藍芽協議棧Bluez的移植使用和配置(寫的狠不錯) .
ARM平臺上藍芽協議棧Bluez的移植使用和配置
藍芽協議棧分析
在Android4.2中實現bluetooth A2dp Sink（二）——移植Android5.0藍芽協議棧
在Android4.2中實現bluetooth A2dp Sink（一）——移植Android5.0藍芽協議棧
CC2640R2F BLE5.0 藍芽協議棧通用屬性配置檔案（GATT）
nrf51822 藍芽協議棧 API 入門
Bluedroid: 藍芽協議棧原始碼剖析
BlueTooth: 藍芽協議棧實現模式分析
藍芽協議4.0、4.1、4.2的比較
1、藍芽核心技術瞭解（藍芽協議、架構、硬體和軟體筆記）
藍芽協議分析_BLE連線有關的技術分析
藍芽協議（1）-- 基本協議
藍芽協議分析(11)_BLE安全機制之SM
藍芽協議 HFP,HSP,A2DP,AVRCP,OPP,PBAP
藍芽協議分析(8)_BLE安全機制之白名單
藍芽協議分析(6)_BLE地址型別
藍芽協議分析(9)_BLE安全機制之LL Privacy
藍芽協議學習整理（二）藍芽協議規範（射頻、基帶鏈路控制、鏈路管理）
藍芽協議-----之pan profile on bluedroid