简介：基于Visual C++的蓝牙HCI通信程序源代码，面向初学蓝牙编程或希望深入理解蓝牙协议栈的开发者，解决在Windows环境下通过HCI接口实现主机与蓝牙控制器之间数据交互的问题。压缩包共25个文件，以.h头文件和.cpp源文件为主体（分别用于接口声明与核心逻辑实现），辅以工程配置、界面资源与说明文档，整体体积仅69KB，结构清晰，便于按模块查阅。目前已有591人学习参考，适合作为蓝牙入门实践的参考资料。代码覆盖蓝牙适配器初始化与参数配置、HCI命令发送及事件响应、数据包封装与收发、通信错误处理、安全配对机制以及基于SDP的蓝牙服务发现等关键环节，同时借助Windows蓝牙API实现设备查找、连接与数据传输。读者可借此掌握VC环境下蓝牙应用开发的基本流程，理解HCI层在协议栈中的位置与运作方式，也能为后续扩展自定义蓝牙服务或低功耗蓝牙应用积累基础。
1. 蓝牙VC开发绕不开的BluetoothHCI：这个标题在讲什么
用 Visual C++ 做过蓝牙串口或 SPP 项目的人应该碰到过这种场景：代码没变，换一个 USB 蓝牙适配器就连接失败；或者想在做连接之前拿到周边设备的 RSSI，却被系统上层的蓝牙 API 挡在外面。稍微往底层探就会发现，绝大多数射频行为都由蓝牙控制器完成，而 Host 与 Controller 之间的对话接口就是 HCI。这个标题里的“BluetoothHCI 蓝牙VC源代码”，核心就是绕过 RFCOMM/GATT 那层封装，用 VC++ 自己构造 HCI 命令包、解析 HCI 事件包。它适合驱动调试、协议分析、产测工具开发，也适合想做蓝牙测距但不想依赖手机 SDK 的开发者。下文直接给出可在 Visual Studio 里编译的最小实现。
2. HCI层在蓝牙协议栈中的角色与VC访问路径
2.1 Host与Controller之间到底隔了什么
现代蓝牙协议栈在逻辑上分成 Host 和 Controller 两半。Host 侧运行 L2CAP、RFCOMM、GATT 等协议，负责服务发现、连接建立和数据封装；Controller 侧负责物理信道、跳频、扫描、寻呼、链路连接和收发时序。二者之间的分界线就是 HCI，规范里把这条分界线做成命令和事件的接口。标题里提到的 BloothHCI 源代码，本质上就是在 Host 侧自己实现这个接口，然后通过一个传输通道把命令发给 Controller，再接收 Controller 上报的事件。
很多 VC 工程师习惯用 Winsock 的 AF_BTH 或 Windows 的 RFCOMM API，这些接口拿不到 HCI 事件，也无法直接控制底层扫描参数。当你需要知道某个经典蓝牙设备的 RSSI，或者要让模块进入低功耗监听模式时，高层 API 往往没有暴露对应能力。HCI 层则把射频控制权全部交出来，代价是字节流要自己编自己拆，调试也从方便的函数调用变成十六进制打印。
2.2 HCI三类数据包和命令帧结构
一个 HCI 包以 1 字节包类型开头。经典蓝牙和蓝牙 LE 在这一层的格式基本一致，常见包类型如下表：
| 包类型 | Packet Indicator | 用途 |
|---|---|---|
| HCI Command | 0x01 | Host 下发命令给 Controller |
| HCI ACL Data | 0x02 | 承载 L2CAP 及应用数据 |
| HCI Synchronous | 0x03 | SCO/eSCO 语音数据 |
| HCI Event | 0x04 | Controller 返回事件给 Host |
这里主要关注 0x01 和 0x04。HCI Command 包的结构为：包类型(1) + OpCode(2) + 参数总长度(1) + 参数(0-255)。OpCode 是高 6 位 OGF 和低 10 位 OCF 拼起来的 16 位小端整数。以 HCI_Reset 为例，OGF=0x03Controller & Baseband，OCF=0x0003，OpCode 就是 0x0C03，写入串口时字节序为 03 0C。参数长度为 0，所以整帧只有 4 字节：
// HCI Command: Reset, OpCode=0x0C03, Parameter Length=0 BYTE hci_reset_cmd[] = { 0x01, 0x03, 0x0C, 0x00 };Controller 收到后返回 Command Complete 事件，事件码 0x0E，紧接着是参数长度、Num_HCI_Command_Packets、命令 OpCode 和状态。正确解析后的结果应该是：
// HCI Event: Event Code=0x0E, Param Len=4 // Num Packets=1, Opcode=0x0C03, Status=0 BYTE hci_reset_evt[] = { 0x04, 0x0E, 0x04, 0x01, 0x03, 0x0C, 0x00 };这里最容易出错的是 OpCode 的小端顺序：看到 03 0C 时不要按文档写成 0x030C。这层细节也正是“BluetoothHCI 源码”里最值得先看的部分。
2.3 VC环境下做HCI调试的通道选择
在 Windows 上原生访问 HCI 设备并不统一，不同蓝牙适配器的驱动对用户态开放的接口差异很大。我一般会换一种更可控的方式：让蓝牙模块工作在 HCI over UART 模式，通过 USB 转 TTL 接进 PC，Visual Studio 里用 CreateFile 打开 COM 口，按 H4 协议发送 HCI 帧。这样不依赖厂商私有 SDK，代码在嵌入式平台和 PC 上都能跑。
连接通道确认后，先不用写完整代码，直接用串口助手发送01 03 0C 00，如果模块回04 0E 04 01 03 0C 00，说明 HCI 链路没问题。如果没回，先查 RX/TX 是否接反，再看模块是否真的处于 HCI 模式。很多双模模块上电默认是透传或 AT 指令模式，需要拉高特定 GPIO 进入 HCI，这一点必须在模块手册里确认。
3. 用VC++写HCI命令帧与事件解析的最小源码
3.1 先把HCI字段装进字节数组：一个能跑的Reset
最小可用的 VC++ 工程不需要 MFC，也不用第三方库，Win32 控制台项目就够。核心步骤只有三步：打开串口、配置 DCB、写入 HCI 帧。下面这段代码可以直接用来验证 HCI_Reset：
#include <windows.h> #include <stdio.h> HANDLE hCom = CreateFileA("COM3", GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL); if (hCom == INVALID_HANDLE_VALUE) { printf("Open COM3 failed: %u\n", GetLastError()); return 1; } DCB dcb = { sizeof(dcb) }; GetCommState(hCom, &dcb); dcb.BaudRate = 115200; // 以模块手册为准 dcb.ByteSize = 8; dcb.Parity = NOPARITY; dcb.StopBits = ONESTOPBIT; dcb.fOutxCtsFlow = FALSE; // 不确定时先关闭硬件流控 dcb.fRtsControl = RTS_CONTROL_DISABLE; SetCommState(hCom, &dcb); BYTE reset[] = { 0x01, 0x03, 0x0C, 0x00 }; DWORD written = 0; if (!WriteFile(hCom, reset, sizeof(reset), &written, NULL)) { printf("WriteFile failed: %u\n", GetLastError()); }这段代码里最需要改的不是帧内容，而是 DCB 参数。HCI over UART 的 H4 传输固定为 8 数据位、无校验、1 停止位，但波特率因模块而异：老式经典蓝牙模块多数是 9600 或 57600，BLE 4.0 以上模块常见 115200。直接把CreateFileA里的COM3替换成实际端口，就可以跑第一轮命令行测试。
3.2 读返回事件：识别0x04后的结构
发送 Reset 后要立刻读事件，最直接的读法是先读 1 字节拿到包类型，再读 1 字节拿到参数总长度，最后按长度读完剩余部分。对应伪代码如下：
BYTE buf[256] = { 0 }; DWORD got = 0; ReadFile(hCom, buf, 1, &got, NULL); // Packet Indicator if (buf[0] != 0x04) return; // 不是 Event Packet 就不处理 ReadFile(hCom, buf, 1, &got, NULL); BYTE plen = buf[0]; // Parameter Length ReadFile(hCom, buf, plen, &got, NULL); // Event Code + 参数这个读法在低速、小包、命令简单时能用，但不严谨。ReadFile返回的字节数可能小于你要求的长度，尤其当模块通过 USB 转 TTL 接入时，HCI 事件可能被驱动拆成两三次到达。正确做法是写一个ReadExact循环，像接收完整帧一样处理。
3.3 封装成C++类并处理粘包
多点几次命令后就会遇到串口最常见的“粘包”：上一次事件的尾部和下一次事件的头部同时出现在缓冲区里。解决办法是每次收到字节后先存入内部缓冲区，然后按包类型和长度字段判断是否已经凑够一包，凑够了再交给上层解析。放在 VC++ 里可以很自然地封装成类：
class HciTransport { public: bool Open(const char* port, DWORD baud); bool Send(BYTE* cmd, size_t len); int ReadEvent(BYTE* out, int maxOut); private: HANDLE hCom_; BYTE frameBuf_[256]; int frameLen_; };Send负责写串口，ReadEvent负责从 frameBuf_ 里截取完整事件包。类内部只需要维护两个状态：已经收到多少字节、当前包的预期总长度。这种写法比每次临时分配缓冲区更容易排查“事件解析错位”问题，也方便后续扩展到 HCI_LE_Meta 事件这类等长不固定的场景。
3.4 在Visual Studio里快速验证
在 Visual Studio 中新建一个空控制台工程，把上述代码粘贴进 main，按 F5 调试。断点打在ReadEvent返回后，打开“内存”窗口查看收到的字节，能直观确认04 0E 04 01 03 0C 00这套结构。如果要换 COM 口，直接在代码里改CreateFileA的端口名即可。
这一步很容易忽略的是串口助手的“发送新行”选项。很多串口工具默认在帧尾追加0A，导致 HCI 包变成01 03 0C 00 0A，模块可能能解析，但后续调试时事件边界会被破坏。建议所有测试都用十六进制发送，并关闭追加换行。
4. HCI over UART 的串口参数、流控与常见坑
4.1 为什么事件会漂移：DCB必调参数
HCI over UART 没有额外的 CRC，也不做波特率自动协商，模块固件写死什么参数就得按什么参数收。很多“看起来像 HCI 帧没写对”的现场其实都是流控不匹配。我在多款蓝牙模块上默认使用下面这组参数：
| 参数 | 建议值 | 备注 |
|---|---|---|
| BaudRate | 115200 | 以模块手册为准 |
| ByteSize | 8 | 固定 |
| Parity | NOPARITY | 固定 |
| StopBits | ONESTOPBIT | 固定 |
| fOutxCtsFlow | 根据模块是否启用 CTS | 不确定时先 FALSE |
| fRtsControl | RTS_CONTROL_DISABLE/HANDSHAKE | 与上一项配合 |
如果模块默认开了硬件流控而代码没有，Controller 可能不会丢字节，但会在 RTS 信号拉低时停止发送，导致事件迟迟不到。反之，代码开了硬件流控而模块没接 CTS/RTS，机会出现命令一直未得到响应。调试初期我会先把流控全部关闭，等命令通路确认正常后再按需打开。
4.2 解析不到Command Complete时的排查顺序
当 VC 程序一直等不到04 0E，不要急着改代码。先从物理链路开始往回推。用一段最原始的循环把收到的每个字节都打出来，比任何断点都直观：
BYTE c; DWORD n; while (true) { if (ReadFile(hCom, &c, 1, &n, NULL) && n == 1) { printf("%02X ", c); fflush(stdout); } }如果打印结果里没有任何字节，先检查 RX/TX 是否接反，再确认模块是否处于 HCI 模式。如果打印出大量FF或随机字符，多半是波特率不匹配。如果收到04 0E但参数少一截，则是 ReadFile 没有按完整长度读取，需要改用 3.3 节的累积读取逻辑。
这里还有一个经典蓝牙与 BLE 的差异点：经典蓝牙模块的 Command Complete 事件里，OpCode 直接对应命令包里的 OpCode；BLE 命令则经常返回04 0E 04 01 XX XX 00，但是很多双模模块会先返回一个 Command Status04 13，随后再返回 Connection Complete 等异步事件。看到两个事件码都别急着认为出错，先看 Status 字节是不是 0。
4.3 版本差异：经典蓝牙与BLE HCI的不同处理
HCI 规范里 OGF=0x01 是 Link Control 组，经典蓝牙的 Inquiry 命令在这一组；OGF=0x08 是 LE Controller 组，BLE 扫描和连接命令都在这里。标题里只写了 Bluetooth 和 VC，说明源码很可能要同时兼容经典和 LE，这时不能把事件表按固定数组一次性写完，建议按 OGF 分派解析函数。
BLE 5.0 之后还新增了HCI_LE_Extended_Create_Connection、Periodic Advertising 等事件，事件码和参数布局比经典蓝牙复杂得多。遇到这类命令时，我会把ReadEvent收到的原始事件先落盘一份，再对照 Core Spec 的对应版本逐字节核对。固件版本和 HCI 规范版本不一致是低层开发最好用的调试点之一。
5. 用HCI_Inquiry_Result_with_RSSI做一个蓝牙测距起点
5.1 让HCI进入Inquiry状态
拿到 RSSI 最直接的方式是经典蓝牙的 Inquiry 过程。HCI_Inquiry 命令的参数有 3 字节 LAP、1 字节扫描时长、1 字节响应数量上限。使用 GIAC 的 LAP=0x9E8B33，扫描时长设为 5 秒，命令包如下：
BYTE inquiry[] = { 0x01, // Command Packet 0x01, 0x04, // OpCode: OGF=0x01, OCF=0x0001 0x05, // Parameter Length 0x33, 0x8B, 0x9E, // LAP: GIAC 0x05, // Inquiry_Length: 5 秒 0x00 // Num_Responses: 0 表示不限 }; WriteFile(hCom, inquiry, sizeof(inquiry), &written, NULL);命令发出后，Controller 会周期性上报HCI_Inquiry_Result（0x02）或带 RSSI 的HCI_Inquiry_Result_with_RSSI（0x22）。支持哪个取决于固件，建议两个事件码都保留解析入口。
5.2 从RSSI事件里提取dBm并做距离粗估
当收到 0x22 事件时，RSSI 字段位于事件参数末尾，是一个有符号单字节数。最简单的方式是把该字节直接接射为 dBm 输出：
// evt 指向 0x22 事件参数区，rssi 位于末尾 signed char rssi = (signed char)evt[evtLen - 1]; printf("RSSI = %d dBm\n", rssi);单次 RSSI 抖动很大，要用于测距至少先做 20 组滑动平均，再套路径损耗模型distance = 10^((TxPower - RSSI) / (10 * N))。其中 N 是环境衰减因子，室内通常取 2 到 4，需要自己在固定距离上标定。注意有些适配器返回的 RSSI 是相对本机接收灵敏度的偏移值，不能直接当绝对功率，统一用同一台机器、同一根天线做对比排序更可靠。把每一条 RSSI 和串口接收时间戳写入 CSV，再结合实测距离拟合 N 值，就能得到可用的近距测距参考。
本文还有配套的精品资源，点击获取
