BLE协议栈 – HCI

HCI（Host Controller Interface）层中文称为主机与控制器接口，它连接主机（Host）和控制器（Controller），将主机的操作转化成HCI指令传给控制器，BLE协议规定了HCI的指令集。

单芯片与双芯片

在BLE协议栈的层模型中，位于下部的物理层、链路层、DTM属于控制器，位于上部的L2Cap、ATT、GATT、GAP、SM层则属于主机，在主机之上用户自己的程序称为用户程序。因此BLE协议栈进一步可以抽象为三层：控制器、主机和用户程序。

BLE协议栈规划的芯片实现方案有单芯片方案，双芯片方案和三芯片方案。
单芯片方案即主机和控制器在同一颗芯片内，双芯片方案是主机和控制器分属两颗不同芯片，三芯片方案则是将用户程序也放在单独芯片内。单芯片放置协议栈全部内容，势必需要巨大Flash和SRAM，而早期主流的芯片资源可能并没有那么充裕，因而提出双芯片方案。

我们知道，BLE协议诞生于2010年推出的Bluetooth 4.0，当时ARM已经大行其道，说芯片没有资源是站不住脚的，但是为什么还是有这个双芯片方案的考虑呢？这需要用历史的眼光去看到BLE协议。BLE脱胎于蓝牙协议，在许多方面借鉴和集成了经典蓝牙的既有特征，在追求低功耗这个目标的路上，也尽量保持蓝牙协议栈核心架构的原始面貌。而经典蓝牙由来已久，所以我们可以猜测，这样的双芯片方案甚至三芯片方案的设计是从经典蓝牙那边继承过来的特性。

实际上，双芯片方案仍然可以在市面上寻到，比如ST的BLE协处理器，就是一颗单独的BLE控制器。使用时只要在任意一个ST的MCU中下载Host固件即可实现主机功能，两颗芯片通过SPI接口进行通信，组成双芯片方案。这样带来的好处也是显而易见，就是可以复用已有的MCU，实现各种资源配置的BLE主机。然而在单芯片方案中，HCI的地位是很尴尬的。我们观察协议栈，物理层属于硬件实现，一部分链路层的功能，比如校验、白化、导引字的识别等功能也是硬件实现，除此之外，协议栈的其他部分均是在固件中实现。所以协议栈其实可以被认做一个固件程序。在单芯片方案中，主机和控制器是写在同一个程序之中两个模块，还要增加一个HCI层来转发消息实属浪费。因此，在某些协议栈的实现代码中，HCI虽然存在，但是其功能已经十分模糊，不再承担主机和控制器之间完整的消息转发功能。

下图为Nordic的一个协议栈实现图，在右图中，HCI从逻辑已经被抹去。（从图上水印可知其来自FutureTek-2014微信公众号的文章： 链接 ）

HCI的用途

就单芯片而言，HCI主要有两个用途。
一个是保持对BLE协议栈的兼容性，既然SPEC这样定义，那么协议栈IP供应商也就这么实现。另一个是用于BLE的RF测试。面向BLE的RF测试的设备，都会配备一个UART接口用于数据通信，而HCI在外部就表现为一个UART接口，这样在测试时，直接用UART线连接测试设备与芯片的UART管脚即可。软件层面，BLE SPEC提供一套HCI指令，测试设备自动收发处理，无需人工干预。结合上一期介绍的DTM层，我们可以简单理解，DTM和HCI就是为BLE的RF测试而存在的。DTM定义了测试内容和格式，HCI提供通信接口

使用HCI

假如安装了Cypress Kit 042-BLE的帮助文件，可以在安装目录下找到DTM的示例工程：PSoC_BLE_DTM。该工程演示了如何使用DTM和HCI进行BLE测试。
很遗憾，该工程过于简单，导致用户一脸懵懂，不知示例为何。其实正如前面所说，RF测试设备通常已经配备了自动发送命令，处理数据的能力，因此只要将BLE配置为DTM模式，并且指定HCI串口管脚即可，无需其他额外操作，所以我们看到工程的main文件中未添加任何操作代码。

 

[本文转自红旭论坛，看完之后获益良多，故联系大佬Wireless-tech转之。]