沁恒蓝牙BLE从机Peripheral讲解二（连接参数协商与多主连接实战）

1. 连接参数协商：从机如何主动“要价”

在上一篇文章里，我们聊透了广播间隔和连接间隔这两个基础概念，知道了它们就像蓝牙设备的“心跳”和“握手”频率。很多朋友看完后，在实际项目中配置了参数，但发现手机连上后，实际的连接间隔和自己代码里写的好像不太一样。有时候数据传输慢得像蜗牛，有时候功耗又高得吓人，心里直犯嘀咕：我明明设置好了，怎么不听我的呢？

这里就引出了BLE连接中一个非常关键，但又容易被忽视的机制：连接参数协商。你可以把它想象成一场“商业谈判”。你的从机设备（比如一个智能手环）是供应商，它心里有一个理想的供货周期（连接间隔），希望既能让客户（手机主机）满意，自己又不太累。而手机主机是客户，它也有自己的一套采购习惯和节奏。连接建立后的第一次“握手”，其实就是双方在交换彼此的“报价单”。

默认情况下，这场谈判是由客户（主机）主导的。 手机会根据自己的策略（比如是iOS还是安卓，甚至是不同品牌手机的电源管理策略）来最终拍板，决定一个它认为合适的连接间隔。这就导致了一个常见问题：你作为设备开发者，精心为你的传感器数据流设置了一个20ms的间隔以求快速响应，但手机可能一上来就给你定了个100ms甚至更长的间隔，理由是“为了省电”。结果就是，你的设备响应变慢，用户体验大打折扣。

所以，我们不能只当被动的“供应商”，得学会主动出击。沁恒的BLE协议栈为我们提供了从机端发起参数更新请求的“谈判工具”——GAPRole_PeripheralConnParamUpdateReq 函数。这个函数允许你的从机设备在连接建立后的任何时刻（通常是在连接稳定后），主动向主机提出修改连接参数的请求。

这个请求里包含几个核心“谈判条件”：

• 期望的最小连接间隔：你的底线，不能再慢了。
• 期望的最大连接间隔：你的理想上限，不希望比这更频繁。
• 从机延迟：允许从机“旷工”多少次连接事件而不被开除。设置为0表示每次都得响应，设置成n，意味着从机可以跳过n次连接事件去干别的活（比如采集一个需要长时间计算的数据），然后再在下一次事件中回复，这对降低功耗很有用。
• 监督超时：连接“失联”多久算彻底断开。这个时间必须大于 (1 + 从机延迟) * 最大连接间隔 * 2，否则很容易被误判掉线。

我刚开始用的时候，以为调用一次这个函数就万事大吉了。结果踩了个坑：主机可能拒绝你的请求！是的，客户（主机）有权拒绝你的新报价。尤其是在多任务繁忙的手机上，系统可能出于整体功耗考虑，驳回你缩短间隔的请求。因此，一个健壮的参数协商逻辑必须是“有策略的重试”。

就像原始文章里那个实例代码展示的，你不能只问一次。我的实战经验是：实现一个带状态机和超时重试