BLE实战：基于TI CC2564x实现PASP手机警报与HOGP键盘模拟

1. 项目概述与核心价值如果你正在开发智能手表、蓝牙耳机或者任何需要与手机进行状态同步的物联网设备那么“手机警报状态”这个功能你一定不陌生。想象一下你的智能手表能实时显示手机是静音模式还是响铃模式甚至能一键让手机静音这个功能背后的核心技术就是蓝牙低功耗BLE规范中的手机警报状态服务Phone Alert Status Service, PASS。同样如果你想让一个简单的BLE设备模拟成键盘向手机或电脑发送按键信息比如做一个蓝牙遥控器或者演示翻页笔那你需要的就是HID over GATTHOGP协议。这次我们不谈空洞的理论直接上手实操。我将以德州仪器TI的CC2564x蓝牙模块及其配套的演示固件为例带你从零开始一步步拆解如何实现PASP和HOGP这两个经典应用。你会发现看似复杂的BLE服务交互其实是一系列有章可循的命令操作。无论是服务端的服务注册与广播还是客户端的扫描、连接、服务发现与配置我都会结合我实际调试中的经验和踩过的坑为你提供一份可以直接“抄作业”的指南。无论你是刚接触BLE的新手还是想深入了解GATT交互细节的开发者这篇文章都能让你对BLE应用开发有一个透彻的理解。2. 环境准备与硬件平台解析在开始敲命令之前我们必须把“战场”准备好。TI的这套演示代码优势在于其跨平台性但不同的硬件平台在细节上仍有差异理解这些差异是成功的第一步。2.1 硬件平台选择与连接提供的Demo支持Tiva™ C系列、MSP432™和STM32F4系列平台。虽然核心的BLE协议栈和应用程序逻辑是通用的但不同平台的启动流程、外设驱动和调试接口略有不同。Tiva平台如TM4C129系列性能较强通常使用XDS110调试器在电脑上会虚拟出一个串口COM口。MSP432平台基于ARM Cortex-M4F的低功耗微控制器同样使用XDS110调试器。STM32F4平台在STM32 Discovery或Nucleo板上运行可能使用ST-LINK虚拟串口。实操要点无论你手头是哪块板子第一步永远是通过USB线将开发板连接到电脑。连接后你需要打开Windows的“设备管理器”在“端口COM和LPT”下找到新出现的设备。它的名字可能是“XDS110 Class Application/User UART (COMx)”、“Tiva Virtual COM Port (COMx)”或类似的。记住这个COMx的编号比如COM5这是我们与板子通信的通道。注意如果设备管理器里没有出现新的COM口可能是驱动未自动安装。你需要根据开发板型号去TI官网下载并安装相应的“CDC串行驱动程序”或“XDS110驱动”。这是最常遇到的第一个坑。2.2 串口终端配置与固件烧录找到COM口后我们需要一个终端软件来和板子“对话”。PuTTY是一个经典且免费的选择当然你也可以使用Tera Term、SecureCRT或VS Code的串口插件。串口参数是固定的必须严格设置波特率Baud Rate对于Tiva、MSP432、STM32F4平台设置为115200。但请注意文档中提到MSP430平台另一个系列使用的是9600我们这里不涉及MSP430所以统一用115200。数据位Data Bits8停止位Stop Bits1奇偶校验ParityNone流控制Flow ControlNone在PuTTY中选择“Serial”连接类型填入正确的COM口和上述参数然后点击“Open”。打开终端窗口后按一下开发板上的复位按钮通常是标有RST或RESET的按键。此时你应该在终端里看到一串初始化信息最后会显示一个命令帮助菜单列出了所有可用的命令如AdvertiseLEConnectLERegisterPASS等。看到这个恭喜你硬件环境和通信链路已经就绪。关于固件本文假设演示固件包含BLE协议栈和PASP/HOGP应用代码已经预先烧录到你的开发板中。如果板子是全新的你需要使用TI的CCSCode Composer Studio或Uniflash工具将提供的*.bin或*.hex演示文件烧录到微控制器的Flash中。烧录过程本身不是本文重点但确保你运行的是正确的演示固件至关重要。3. PASP应用深度解析与实战PASPPhone Alert Status Profile定义了如何通过BLE传递手机的警报状态。它包含两个角色服务器Server和客户端Client。通常手机作为服务器智能手表或车载系统作为客户端。服务器维护着警报状态铃声、震动、显示和响铃设置静音/正常并能在状态改变时通知客户端。客户端则可以读取状态并请求服务器进入或取消静音模式。3.1 服务器端服务注册与广播我们要搭建一个最简单的PASP通信环境至少需要两块开发板一块作为服务器一块作为客户端。步骤1启动服务器并注册PASP服务在作为服务器的板子的串口终端中输入命令RegisterPASS这条命令会调用底层的PASS_Initialize_Service()API。它的作用是向本地的GATT服务器注册一个PASP服务。成功执行后会返回(0) Successfully registered PASP Service。这意味着你的设备现在“拥有”了PASP服务但其他设备还无法发现它。步骤2开启低功耗广播接着输入命令AdvertiseLE 1AdvertiseLE命令的参数1表示开始广播。此时服务器设备会开始向外发送BLE广播包包中包含了它的设备地址和部分服务信息高声宣布“我在这里并且我支持PASP服务”。在终端中你可能会看到类似Advertising Started的提示。实操心得广播间隔和广播数据是可以配置的。默认的演示固件通常使用标准间隔。在实际产品中你需要权衡功耗和被发现的速度。更短的间隔如20ms能让设备更快被扫描到但更耗电更长的间隔如1秒以上则更省电。3.2 客户端端设备发现与连接建立现在切换到作为客户端的开发板。步骤1扫描周围的BLE设备在客户端终端输入StartScanning客户端会开始监听空中的广播包。几秒钟后你应该能在终端滚动信息中看到发现的设备列表其中包含服务器的设备名称如果广播中包含了和一个唯一的蓝牙设备地址格式类似00:1A:7D:DA:71:13。这个地址是设备的硬件标识至关重要。步骤2停止扫描并记录地址看到目标设备后输入StopScanning停止扫描以节省功耗。请务必记下目标服务器设备的蓝牙地址。步骤3发起连接使用记下的地址发起连接ConnectLE 00:1A:7D:DA:71:13请将00:1A:7D:DA:71:13替换为你实际看到的地址。如果连接成功终端会显示Connection Successful或类似的提示。至此一个BLE物理链路已经建立但高层应用PASP的通信通道还未就绪。3.3 服务发现与特征配置连接建立后客户端需要知道服务器到底提供了哪些服务以及如何与这些服务交互。步骤1发现PASP服务在客户端终端输入DiscoverPASS这个命令会触发一次GATT服务发现过程。客户端向服务器查询其GATT数据库中的所有服务。发现完成后终端会打印一个摘要核心是告诉你服务器是否支持PASP服务以及该服务下有哪些特征Characteristic是可用的。对于PASP关键特征包括警报状态Alert Status可读、可通知Notify。响铃设置Ringer Setting可读、可通知Notify。响铃控制点Ringer Control Point可写Write用于控制静音。步骤2配置通知使能数据推送发现服务后客户端需要告诉服务器“当警报状态或响铃设置变化时请主动通知我。”这就是配置CCC客户端特征配置描述符。ConfigureRemotePASS 1 1这个命令有两个参数第一个1启用警报状态通知。第二个1启用响铃设置通知。 命令执行成功后服务器端对应的特征就进入了“通知使能”状态。此后一旦服务器端的警报状态或响铃设置发生变化它会自动将新值推送给客户端而无需客户端反复查询。3.4 数据交互与状态同步实战配置完成后整个PASP系统就进入了工作状态。我们来模拟几个典型场景。场景1客户端获取服务器当前状态在服务器端你可以手动触发状态通知在服务器终端输入NotifyAlertStatus。服务器会立即将其当前的警报状态铃声、震动、显示各自是活动/非活动通过通知发送给客户端。客户端终端会显示类似Alert Status Notification Received: RingerActive, VibrateInactive, DisplayActive的信息。在服务器终端输入NotifyRingerSetting。服务器会发送当前的响铃模式静音/正常。客户端会显示Ringer Setting: Normal或Ringer Setting: Silent。场景2服务器更新状态并同步修改警报状态在服务器端使用SetAlertStatus命令。例如SetAlertStatus 1 0 1这三个参数分别代表Ringer铃声1活动Vibrate震动0非活动Display显示1活动。执行后服务器的内部状态被更新。推送更新紧接着在服务器端再次执行NotifyAlertStatus。由于客户端已配置通知它会立刻收到更新后的状态。这就是“通知”机制的优势状态变化后服务器主动推送客户端实时更新效率远高于客户端轮询。场景3客户端远程控制服务器这是PASP的另一个核心功能客户端控制服务器静音。进入静音模式在客户端终端输入SetSilentMode。这条命令会向服务器的“响铃控制点”特征写入一个特定指令。服务器收到后会将响铃设置切换到“静音Silent”。你可以在服务器端用NotifyRingerSetting验证会发现输出变成了Ringer Setting: Silent。取消静音模式在客户端终端输入CancelSilentMode。服务器会退出静音模式。一键静音在客户端终端输入MuteOnce。这个命令会让服务器响铃一次后立即静音适用于临时需要安静的场景。深度解析SetSilentMode和MuteOnce等控制命令使用的是GATT_Write_Without_Response_Request。这种写入方式称为“无响应写入”客户端发送数据后不等待服务器的确认速度快、功耗低适用于这种不需要确认结果的命令型操作。与之相对的是“有响应写入”要求服务器回复确认更可靠但耗时。4. HOGP应用深度解析与实战HOGPHID over GATT允许BLE设备扮演传统USB HID设备的角色如键盘、鼠标、游戏手柄。我们这里以实现一个最简单的BLE键盘为例。4.1 HOGP服务器设置与广播HOGP演示中开发板通常作为HID设备服务器而手机或电脑作为主机客户端。步骤1启动HOGP服务并广播与PASP不同HOGP演示固件通常已将HID服务预注册好。你只需要启动广播即可。在作为HOGP服务器的板子终端输入Advertise 1注意这里用的是Advertise而不是PASP中的AdvertiseLE。这是因为这个演示可能使用了不同的广播参数集。启动后设备会以名称“HOGPdemo”或其他预设名称进行广播。4.2 主机端连接与配对步骤1手机扫描与配对打开手机的蓝牙设置开始扫描设备。你应该能看到名为“HOGPdemo”的设备。点击它进行配对。根据BLE安全要求可能会弹出配对请求如输入PIN码或点击确认在演示中通常使用“Just Works”模式直接确认即可。配对成功后手机和开发板都会显示已连接。注意事项HOGP连接通常需要配对Pairing和绑定Bonding过程以建立加密链路并交换密钥确保HID输入的安全性。这是与PASP演示的一个关键区别PASP演示可能为了简化使用了无安全要求的连接。4.3 HID数据发送模拟键盘输入连接建立后HID报告通道就已就绪。我们可以让开发板模拟键盘发送字符。步骤1发送键盘报告在开发板服务器的终端输入NotifyKeyboardReport a这条命令会构造一个包含字符‘a’键值的HID键盘输入报告Input Report并通过通知Notification发送给已连接的手机。NotifyKeyboardReport命令内部调用了HIDS_Notify_Input_ReportAPI并指定报告类型为rtBootKeyboardInputReport引导协议键盘输入报告。步骤2在手机端验证在手机上打开任何一个文本编辑器如备忘录、短信输入框。当你在开发板终端执行上述命令后手机的文本输入框内应该立即出现一个字母“a”。你可以尝试发送不同的字符如NotifyKeyboardReport b、NotifyKeyboardReport Space发送空格等。步骤3理解HID报告描述符演示固件发送的‘a’字符其本质是一个符合USB HID键盘Usage Table的扫描码Scan Code数据包。真正的HOGP设备在初始化时会通过“报告描述符Report Descriptor”告诉主机它是什么类型的设备键盘、支持哪些按键、按键的用法Usage是什么。这个演示固件已经内置了一个标准的键盘报告描述符。在实际开发中如果你需要定义自定义按键如多媒体键你需要修改这个报告描述符。4.4 电池服务集成许多HID设备如无线键盘需要报告电量。HOGP演示通常也集成了电池服务BAS, Battery Service。设置电量水平在服务器终端你可以用SetBatteryLevel命令设置一个模拟的电量值例如SetBatteryLevel 75。通知电量然后使用NotifyBatteryLevel命令将这个电量值主动通知给已连接的主机。主机会在系统蓝牙设备信息中更新电量显示。这展示了如何在同一个BLE设备上组合多个GATT服务HIDS BAS实现复杂功能。5. 核心API与命令原理深度剖析仅仅会敲命令是不够的理解每个命令背后的API调用和BLE协议原理才能举一反三解决实际问题。5.1 PASP核心API解析我们以几个关键命令为例拆解其底层实现RegisterPASS-PASS_Initialize_Service()作用在GATT服务器上创建并注册一个PASP服务实例。关键参数BluetoothStackID: 标识使用哪个蓝牙协议栈在多协议场景下重要。EventCallback: 事件回调函数指针。当客户端写入控制点或配置通知时服务器应用通过此回调获知。ServiceID: 输出参数返回创建的服务实例ID用于后续操作如发送通知。部过程该API会在设备的GATT数据库中添加PASP服务的UUID、定义警报状态、响铃设置、控制点等特征及其权限读、写、通知。DiscoverPASS-GDIS_Service_Discovery_Start()作用启动GATT服务发现过程。关键参数ConnectionID: 与哪个已连接设备的连接。UUIDList: 要查找的特定服务UUID列表。传入PASP服务的UUID可以加速发现。如果为NULL则发现所有服务。ServiceDiscoveryCallback: 发现完成后的回调函数在该函数中解析出PASP服务的特征句柄Handle。协议细节该函数会向服务器发送“读所有主服务”或“按UUID查找服务”的ATT请求然后递归地发现每个服务下的特征和描述符。获取到的特征句柄是后续读写操作的唯一地址。ConfigureRemotePASS 1 1-EnableDisableNotificationsIndications()作用配置客户端特征配置描述符CCCD。关键参数ClientConfigurationHandle: 上一步服务发现得到的CCCD的句柄。ClientConfigurationValue: 写入的值。0x0000禁用通知0x0001启用通知。核心原理CCCD是GATT协议中一个特殊的描述符客户端通过向它写入0x0001来订阅该特征的通知。服务器在特征值变化时会检查其CCCD如果被启用则自动发送通知包给客户端。NotifyAlertStatus-PASS_Send_Notification()作用服务器主动向客户端发送警报状态通知。关键参数CharacteristicType: 指定要通知哪个特征这里是rrAlertStatus。数据流向API内部会根据特征类型找到对应的特征值然后通过ATT_HANDLE_VALUE_NTFPDU协议数据单元发送给客户端。客户端在GATT层接收并解析该PDU然后通过回调函数通知上层应用。5.2 HOGP核心API解析NotifyKeyboardReport-HIDS_Notify_Input_Report()作用发送HID输入报告。关键参数ReportType: 报告类型。rtBootKeyboardInputReport表示这是引导协议键盘报告兼容性最好。InputReportData: 指向实际键盘报告数据的指针。对于‘a’键数据可能类似{0x00, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}其中0x04对应‘a’键的HID使用码。InputReportLength: 报告数据的长度。工作流程应用层构造好键盘扫描码数据调用此API。协议栈将数据封装到HID报告中再通过GATT通知如果主机已使能通知发送出去。手机端的蓝牙协议栈收到后解析HID报告并将其转换为系统的键盘事件。5.3 错误码解读与调试每个API都可能返回错误。文档中列举了如(-4) FUNCTION_ERROR、(-1000) PASS_ERROR_INVALID_PARAMETER等错误码。理解这些错误码对调试至关重要FUNCTION_ERROR(-4)通常表示底层协议栈或系统调用失败可能是内存不足、状态错误。INVALID_PARAMETER类错误 (-1000, -6等)传入的参数非法比如句柄为0、数值超出范围。检查你的命令参数和之前步骤获取的句柄是否正确。INSUFFICIENT_RESOURCES(-1002)系统资源不足无法创建新的服务实例或连接。可能同时运行了太多服务或连接数超限。SERVICE_ALREADY_REGISTERED(-1003)试图重复注册同一个服务。在调用RegisterPASS或类似初始化函数前确保没有重复初始化。当命令失败时仔细查看返回的错误码并结合当前操作步骤是在连接前还是连接后是在配置通知前还是后进行排查这是定位问题最直接的方法。6. 常见问题排查与实战经验在实际开发中你几乎一定会遇到下面这些问题。我把它们和解决方案整理出来希望能帮你节省大量调试时间。6.1 连接与通信类问题问题1StartScanning后找不到设备。可能原因1服务器未开始广播。确认服务器端已成功执行AdvertiseLE 1或Advertise 1并有成功提示。可能原因2广播间隔太长或广播数据不包含完整服务UUID。演示固件通常广播完整UUID。如果自定义确保广播数据ADV Data中包含了PASP或HOGP的UUID或至少是通用可发现标志。可以尝试让服务器和客户端靠得更近。可能原因3物理信道干扰。换个环境试试避开Wi-Fi路由器等2.4GHz干扰源。问题2ConnectLE失败提示超时或错误。可能原因1地址错误。蓝牙地址是区分大小写的十六进制且冒号分隔。仔细核对确保没有输错或混淆0和O1和I。可能原因2设备已停止广播。BLE设备在连接后会自动停止广播。确保你在客户端扫描后、连接前服务器一直处于广播状态。可能原因3设备已连接到其他主机。一个BLE从设备服务器通常一次只能接受一个主设备客户端的连接。确保服务器没有被手机或其他设备占用。问题3DiscoverPASS失败或未发现服务。可能原因1服务未正确注册。确认服务器端RegisterPASS命令返回成功0。可能原因2连接未真正建立。虽然ConnectLE返回成功但底层的链路可能不稳定。尝试断开重连。可能原因3MTU大小不足。服务发现过程需要交换多个ATT数据包。如果默认的ATT MTU通常是23字节太小可能导致复杂的服务发现失败。一些协议栈支持MTU交换但演示命令可能未启用。这通常不是演示中的问题但在复杂自定义服务中需注意。6.2 通知与数据交互类问题问题1客户端收不到NotifyAlertStatus或NotifyKeyboardReport发送的通知。首要原因未配置CCCD。这是最常见的原因在PASP中必须确保客户端执行了ConfigureRemotePASS 1 1。在HOGP中连接和配对过程通常由主机手机自动完成CCCD的配置。如果收不到检查主机端手机蓝牙设置是否授予了正确的权限如“允许访问输入设备”。可能原因2连接已断开。通知只能在活跃的连接上发送。检查连接是否保持。可能原因3特征不支持通知。确认服务发现的结果中该特征的属性Properties包含了Notify标志。问题2SetSilentMode等控制命令执行后服务器端状态无变化。可能原因客户端未发现或写错了“控制点”特征的句柄。SetSilentMode命令需要向服务器的“响铃控制点”特征写入特定指令。如果服务发现阶段未能正确获取该特征的句柄写入就会失败。检查DiscoverPASS的输出确认所有必要的特征Alert Status, Ringer Setting, Ringer Control Point都被成功发现。6.3 性能与稳定性优化建议连接参数协商BLE连接后主从设备会协商连接间隔、从机延迟、监督超时等参数。更短的连接间隔如15ms意味着更快的响应速度但功耗更高。演示固件通常使用默认值。在产品开发中你需要根据应用场景是频繁交互的遥控器还是偶尔同步数据的传感器来优化这些参数以在性能和功耗间取得平衡。事件驱动与状态机演示中使用串口命令触发操作是典型的“轮询”式。真实产品中应用逻辑应该是事件驱动的。例如当收到PASS_Event_Callback通知客户端写了控制点时服务器应用才去执行静音操作当手机系统音量改变时才触发NotifyRingerSetting。设清晰的状态机是保证应用健壮性的关键。错误处理与重试机制不要假设每一次ATT操作都能成功。网络可能不稳定。在关键操作如配置通知、发送重要数据后应检查返回值并实现简单的重试逻辑例如最多重试3次每次间隔递增。功耗考量作为外设Peripheral/Server在未连接时应进入深度睡眠仅由广播事件或定时器唤醒。在连接状态下合理利用从机延迟Slave Latency特性允许从设备跳过一定数量的连接事件而不唤醒以进一步省电。TI的协议栈通常提供了相应的低功耗管理接口。通过这套从硬件准备、命令实操到原理剖析、问题排查的完整流程你应该对基于BLE的PASP和HOGP应用开发有了一个立体而深入的认识。记住BLE开发的核心在于理解GATT的“客户端-服务器”模型和“属性”数据库的概念。一旦掌握了这个范式无论是实现标准的蓝牙Profile还是开发自定义的私有服务思路都是相通的定义服务/特征 - 服务器注册/广播 - 客户端发现/连接 - 配置通信方式读/写/通知 - 进行数据交互。剩下的就是在具体的芯片平台和协议栈上熟练运用这些API和调试工具了。