ARM平台上蓝牙协议栈Bluez的移植使用和配置

earching for 0x1112 on 00:02:72:B0:00:26 ...
Service Name: Headset Audio Gateway
Service RecHandle: 0x1001d
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
。。。

7.3.4 Hciconfig
这个就不用多说了，格式上很类似于ifconfig，用来设置HCI设备的参数
例如
hciconfig hci0 up 启动hci0接口
hciconfig hci0 iscan 使能位于hci0接口的蓝牙芯片的inquery scan模式（使得设备能被其它蓝牙设备发现）


8 杂项
8.1 使用Dbus-send进行测试
由于Bluez使用dbus进行进程间通讯，所以我们可以使用dbus-send命令直接发送命令进行一些查询，试验的工作。
Bluez每个Daemon或service所支持的Dbus接口API描述文本，可以在各自的目录下找到，例如Audio的API写在 audio/audio-api.txt中。
以Audio为例，可以参考 /wiki/HOWTO/AudioDevices 中的描述


8.2 HCI、H4、USB、BCSP 之间的关系
个人理解，严格的说HCI和其它几种protocol并不是可以对比的同一层次的东西。
HCI protocol 并不考虑在实际传输载体以及其中的纠错等问题，只是一个抽象的传输层或叫做接口。USB，H3，H4等才是具体的transport layer（此外还有SD Transport layer）。HCI数据包需要附着在这些具体的Transport Layer的协议包中。
以BCSP为例，4种类型的HCI数据包各自使用了一个BCSP通道，做为这些通道的payload封装在BCSP的协议包里，需要通过TTY的lldsic层走一次，并由hci_uart模块做相应的封装工作。而BCSP还通过其它通道支持其它的一些自定的Protocol。BCSP作为一个具体的传输层协议，还支持了校验，同步等功能。
H4机制类似，SD和USB transport好像区别比较大一点。具体可以参考 Bluetooth Specification Volume 4.

8.3 BCSP数据包结构
HCI数据包的结构，在bluetooth的spec里面有详细定义，不过，CSR自己的BCSP，BCCMD等一系列协议，又添加了一堆的东西，其中，HCI数据包是作为BCSP的payload，而BCCMD又是作为HCI的payload，所以测试过程中，发觉要分析清楚bluez通过kernel最后到底往蓝牙芯片的串口发送了什么数据，特别是想要自己手工构建一串数据，着实要看上一堆spec，拼凑起来才能完成。
要具体学习分析一串命令，最好的办法，我能想到的就是修改bccmd的代码，将它传给串口的每一个字符串都打印出来，这样对照这spec看，事半功倍。

例如下面这条，是使用我修改后的bccmd指令。所做的操作是读取串口波特率的pskey：

./bccmd.dbg -t bcsp -d /dev/ttyS1 psget -s 0x0 0x01be

cmd : 00 fc 13 c2 00 00 09 00 01 00 03 70 00 00 b
e 01 01 00 00 00 00 00
c0 d1 65 01 c8 00 fc 13 c2 00 00 09 00 01 00 03 70 00 00 be 01 01 00 00 00 00 69 a6 c0

在这里 HCI的数据包是第一行，具体解释一下：

头4个