既然不可以在中断中使用TMOS EVENT 那我可以直接在中断中调用BLE HID send report的函数吗，会有什么风险？

还有在BLE 工程中启用了 HAL_SLEEP 然后在CH58X_LowPower 中添加了PRINT函数后发现频繁启动这个函数，大概几十ms 一次?

已经设置好了最小链接间隔，和最大连接间隔，把从机延迟也设置到最大了，为什么还是几十毫秒唤醒一次，我的TMOS任务每执行一次就会print一个freq:300这样的数据，所以说看来唤醒系统另有原因，但是我自己只设置了一个TMOS程序，求解达

从这里可以计算出 系统在 300ms 唤醒了12次

这是设置的连接间隔和从机延迟

您好，不建议在中断服务函数中直接调用HID发包函数，也是建议放到TMOS事件里运行，原因和不要在中断服务函数中安排TMOS事件类似：HID发包函数是走BLE发包的，就会涉及到协议栈运行，协议栈无法预期中断什么时候产生，中断里进行的操作可能会影响协议栈的运行。

BLE从机代码里可以设置最大最小连接间隔，是给定了一个范围，连接后实际的连接间隔是要由主从机协商出来的，可以查看串口打印日志中，有一条Int xx，表明了当前连接的实际连接间隔。为了维持BLE连接，协议栈会自动安排唤醒，您可以对照一下该连接间隔和您串口打印唤醒的间隔是否一致。

那发送间隔具体协商过程是什么样的？如何才能获得最大的连接间隔来保证最小的功耗？

BLE广播间隔和连接间隔（CH582） - SweetTea_lllpc - 博客园 (cnblogs.com)

连接间隔协商可查看该博客。

有办法实现蓝牙已经连接上后更换链接间隔吗，还有在TMOS中使用基础的PM会有什么风险，比如基础的Sleep 和 shutdown

连接成功可以调用GAPRole_PeripheralConnParamUpdateReq进行连接间隔的协商更新，注意判断函数的返回值确保协商成功，上面博客有做了讲解，可查看。

基于蓝牙功能已经通过协议栈管理了睡眠，因此只需要管理唤醒的时间去执行自己的任务即可。不需要再手动的去调用Sleep等睡眠状态。这是基于使用蓝牙的基础上处理的。如果不需要使用蓝牙功能，则可以手动的调用Sleep，等到需要醒来执行蓝牙或者其他功能，则可以通过GPIO或者RTC中断唤醒。

睡眠博客可以参考：

CH573芯片Sleep说明（RTC程序说明） - SweetTea_lllpc - 博客园 (cnblogs.com)

好的，谢谢！

这个CallBack 方法是不是默认不使用，我看串口打印上没有这个的打印行

已经在过程中重新协商最小链接间隔了

需要注意的是：

①进入回调函数中才可以确保连接间隔更新成功，因此如果需要再次更新，需要在回调函数中通过tmos任务进行调用下一次的更新；

②GAPRole_PeripheralConnParamUpdateReq需要判断返回值是否为0，0为success；

③你上述的更新参数填写有问题，slavelatency和timeout这两个值一般也不会给上图的那么大的。

又看了遍指导，根据指导完成了对于程序的修改，但是依然没有在串口中受到UpdateCallBack方法PRINT的条目

这是改后的更新语句

可以确定方法已经正确被执行

这是执行的方法

可以看出来前边的DEBUG条目已经成功打印 然后我PRINT GAPRole_PeripherialConnParamUpdateReq方法的返回值，也确认是0

所以我现在还是没有解决更新链接间隔的问题

請查看，如有疑問，請直接發送郵件至郵箱lpc@wch.cn，我們會進行技術支持。

刚才测试了下，我发现只有电脑删除设备以后重新链接才会触发设备延迟更新，但是从机掉电重新链接不会触发设备链接参数更新

这是删除链接后重新链接

可以看到触发了参数更新的Callback

我写了个TMOS循环定时任务更新参数

执行效果如下并没有触发参数更新的CB

这是掉电重新链接的打印，也没有重新协商参数

请教下，具体问题出现在哪个环节，我自己没有什么头绪

刚才又使用CH573 试了下，也存在同样的问题，在测试CH573时发现存在同样的问题

只在HIDKeyBoard例程上修改了这两行代码，其他代码没有改变

邮件已回复。可以参考提供的代码。