HCI是啥？
如上图，HCI就是HOST和Controller之间的通道。用来桥接Host和Controller Devices。
HCI是一个标准的蓝牙用的接口，用来Host发给Controller命令，HOST从controller接收events，和HOST发给Controller数据，和从HOST从Controller接收数据。
HOST就是指我们的主控芯片，Microcontroller/ MCU / μCON / MPU等，比如我正在使用的是iMX6ULL芯片。
Controller就是蓝牙芯片了，比如我比较熟悉的TI的CC2564芯片。
那这两个芯片之间用什么方式通信呢？
用的是串行通讯，主要有两种，一种是UART，另一种是USB。
我们一般以UART为主要使用方式，更方便我们通过外部UART串口工具来抓取HCI通信数据或发送HCI命令给蓝牙芯片。
我们网上搜索蓝牙5.0协议，下载bluetooth-Core_v5.0.pdf，以5.0为例，还有比5.0更高版本的蓝牙spec。
蓝牙协议内容很多，打开后发现里面分了8卷，从Volume 0 ~ Volume 7。
有关HCI的主要部分在Vol 2: Core System package [BR/EDR Controller volume]，Part E: Host Controller Interface Functional Specificaton。
这里面介绍了HCI Flow Control，HCI Data Formats和HCI Commands and Events。
HCI的主要作用，就是HOST可以发送Command给Controller，然后Controller返回Event给HOST。
HCI command的发送形式是以packet来发送。发送的数据如没有特殊说明都是little endian的，先发送低位字节数据。
HCI command的header由3个字节组成，前两个是操作码，第三个是payload长度。所以一个HCI command packet的payload最大是255个字节。
操作码由两部分组成，OpCode Group Field (OGF) and OpCode Command Field (OCF)。两个字节16bit，高6位是OGF，低10位是OCF。
不同的OGF和OCF定义了不同的HCI command，标准的HCI command在core spec中有定义，可以在上面提到章节中查询。
OGF每位都是1时，值为0x3F，这个值保留给厂商自用，vendor-specific debug commands或者用来updating firmware使用，这就是HCI命令是可扩展的，同时也包括相应的扩展的Event。
如下图：
在蓝牙协议文档里， 7 HCI Commands and Events下面，每一小节表示不同类型的HCI commands。
比如，Link Control Commands的OGF是0x01，Link Policy Commands的OGF是0x02，LE Controller Commands的OGF是0x08。
具体的HCI command，可以在相关的种类里查找，对应不同的OCF值。
上面说的是蓝牙core spec里的HCI命令，是标准定义的，关于供应商自由HCI command，以TI CC2564为例，我们找到相关文档，CC256x VS HCI Commands - Texas Instruments Wiki.pdf。
下图截取了一部分：
根据上面的Command的操作码，我们看到都是0xFCxx，0xFDxx，0xFExx和0xFFxx的数值。
这些操作码的高6位的OGF值，都是0x3F，和上面Core Spec里规定的一样。
0xFC = 0b 1111 1100
所以大于0xFC的数值，高六位值都是0x3F。
在TI VS HCI Commands里，HCI_VS_DRPb_Set_Power_Vector （0xFD82），用来设置transmit power，当蓝牙设备不容易被发现，不容易连接或者离远一点就断开连接的话，就可能是Transmit Power Level设置的问题。
这个SetPowerVector命令的具体数据格式：
我们看到对每种不同的信号调制方式（modulation scheme ）使用不同的Power Vector。
在调制类型后，是15个power level的具体的设置值，每个level占一个字节。
比如GFSK的Power Vector数值如下：
那发送的数据是：
0xFD82, 0x13, 0x00, 0x9c, 0x18, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xd2, 0xdc, 0xe6, 0xf0, 0xfa, 0x04, 0x0e, 0x18, 0xff, 0x0000
操作码0xFD82，长度19字节0x13，GFSK信号调制0x00，15个power level数值每个一字节，然后是0xFF和0x0000。
CC2564只使用8个power level，从15到8。每个power level之间相差5dBm。
GFSK的Power level 1是给BLE power使用的。
设置的数值是dBm值乘以2，比如Power 15的dBm是12，则设置值位12x2=24=0x18。
上面列举的数据是默认的power level vector，也可以自己设置不同的数据。在蓝牙设备交互中，如果接收方从天线拿到的信号比较弱，就可以向发送方请求增强power level。反之，如果信号太强，可以请求减弱，以免耗电过多。
发送Command给Controller后，controller会回一个Command Complete Event：
我们在core spec里找到这个event的描述：7.7.14 Command Complete Event
从Controller发给Host的Command Complete Event，第一个字节是Event Code，然后参数数据长度，然后是具体的参数，如上图描述。
Event数据包的数据格式，由Event码值，参数长度和参数内容组成，如下图：
?
关于Event的一些补充说明：
在初始开机时或复位后，主机应最多发送一个待处理的HCI命令包，然后等接收Command Complete 或 Command?Status event。
Command Complete 或 Command?Status event里包含一个参数，叫做Num HCI Command Packets，表示当前可以允许Host发给Controller命令的最大个数。
控制器可以缓冲一个或多个HCI命令包，但控制器应按接收顺序来执行命令。
控制器可以在未完成当前命令时执行下一个命令。所以，命令完成的顺序并不是按照命令开始执行的顺序。
为了向主机表明控制器已经准备好接收HCI命令数据包，控制器可能会产生一个Command Complete 或 Command?Status event，其中命令操作码设置为0x0000，Num HCI Command Packets设置为大于等于1。
命令操作码0x0000是一个特殊值，表示该事件与主机发送的命令无关。
控制器可以随时发送一个命令操作码为0x0000的Command Complete 或 Command Status event，来更新Num HCI Command Packets。
比如发0，就是通知Host不要发送命令，设置大于等于1，就告诉Host，可以发送命令。
对于大多数命令来说，当控制器完成命令时，应向主机发送一个命令完成事件。
有些命令是在后台执行的，当它们完成后不会返回一个Command Complete Event。而相应的，当开始执行时会发送一个Command Status?event，执行结束后和这个命令相关的某个event会从controller发给host。
关于Status Event：7.7.15 Command Status Event。
