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

[speed] [flow|noflow] [bdaddr]

其中最重要的参数就是 type和speed，type决定了要初始化的设备的型号，可以使用 hciattach –l 来列出所支持的设备型号。

并不是所有的参数对所有的设备都是适用的，有些设备会忽略一些参数设置，例如：查看hciattach的代码就可以看到，多数设备都忽略bdaddr参数。

Hciattach命令内部的工作步骤是：首先打开制定的tty设备，然后做一些通用的设置，如flow等，然后设置波特率为initial_speed，然后根据type调用各自的初始化代码，最后将波特率重新设置为speed。所以调用hciattach时，要根据你的实际情况，设置好initial_speed和speed。

对于type BCSP来说，它的初始化代码只做了一件事，就是完成BCSP协议的同步操作，它并不对蓝牙芯片做任何的pskey的设置。同步操作的具体流程和规范可以参考CSR的相关文档： BCSP Link Establishment Protocol

7.3        其它

下面几个，使用了，但是没有太多研究

7.3.1 hcidump

Hcidump不在bluez-utils包里，而是在单独的hcidump包里。主要用来分析捕获和分析HCI数据包，如果使用bluez过程中出了什么问题，用hcidump往往可以发现一些出错的线索，原因。 参数很多，基本上hcidump –X –V 就可以帮你获得详细的经过格式解析的数据包。

7.3.2 hcitool

主要用hcitool来scan远端的设备，显示设备地址，名称等。

例如：Hcitool scan， hcitool inq

7.3.3 sdptool

主要用来浏览远端设备SDP服务，或者管理本地的SDPD维护的数据库。

常用的应该就是查找远端设备的服务了

例如：

sdptool browse 00:02:72:B0:00:26 浏览地址为00:02:72:B0:00:26的设备所提供的服务

sdptool search 0x1112 00:02:72:B0:00:26 查找地址为00:02:72:B0:00:26的设备上的Headset Audio Gateway服务。

./sdptool search 0x1112 00:02:72:B0:00:26

Class 0x1112

Inquiring ...

Searching 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 Hci config

这个就不用多说了，格式上很类似于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为例，可以参考 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.3BCSP数据包结构

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 be 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个字节是HCI Head，其中

00 fc ：整体代表这是一个制造商自定义的命令。

13 ：HCI命令长度为0x13。

C2 ：包的内容是唯一的一个BCCMD数据包。

后面是BCCMD的Head

00 00 ：这是一个GetReq命令

09 00 ：BCCMD的命令9个word长度，及18字节

01 00 ：seqno， 包的顺序标记 包1

03 70 ：varid 7003， 表示这是对PSKEY的操作

00 00 ：状态标志

再下来是BCCMD的payload

be 01 ：0x01be 波特率PSKEY的index

01 00 ：该PSKEY的长度为1

00 00 ：strore 为 00

00 00 ：该PSKEY的值，这里是发送读命令，所以填0

第二行的数据是将HCI包封装在了BCSP数据包里：

前面部分：c0 d1 65 01 c8 ：

C0 ：是BCSP数据包的分割符

D1 ：类型为可靠链接数据流，有CRC校验

65 01 ：channel 5 ( HCI CMD )， 长度为0x16

C8 ：包头的校验

后面部分：69 a6 c0：

69 a6 ：整个BCSP包的CRC校验

C0 ：分隔符

其它命令类似的分析可得。

如果只是希望看到HCI命令本身，也可以用hcidump来看。这是上面的读pskey操作通过HCI接口操作的dump：

< HCI Command: Vendor (0x3f|0x0000) plen 19

BCCMD: Get req: len 9 seqno 1 varid 0x7003 status 0

PSKEY: key 0x01be len 1 stores 0x0000

UART_BAUDRATE: value 0 (0x0000)

8.4 Hid / Serial / HF / OBEX

这几个比较常用的profile，还没测试哪。。。。。。谁给我买个蓝牙鼠标玩玩？！

8.5 总的遗留问题

整体上，PC上实现的自动识别，自动启动服务的一整套脚本，还没有仔细研究。