既然不可以在中斷中使用TMOS EVENT 那我可以直接在中斷中調(diào)用BLE HID send report的函數(shù)嗎，會(huì)有什么風(fēng)險(xiǎn)？

還有在BLE 工程中啟用了 HAL_SLEEP 然后在CH58X_LowPower 中添加了PRINT函數(shù)后發(fā)現(xiàn)頻繁啟動(dòng)這個(gè)函數(shù)，大概幾十ms 一次?

已經(jīng)設(shè)置好了最小鏈接間隔，和最大連接間隔，把從機(jī)延遲也設(shè)置到最大了，為什么還是幾十毫秒喚醒一次，我的TMOS任務(wù)每執(zhí)行一次就會(huì)print一個(gè)freq:300這樣的數(shù)據(jù)，所以說(shuō)看來(lái)喚醒系統(tǒng)另有原因，但是我自己只設(shè)置了一個(gè)TMOS程序，求解達(dá)

從這里可以計(jì)算出 系統(tǒng)在 300ms 喚醒了12次

這是設(shè)置的連接間隔和從機(jī)延遲

您好，不建議在中斷服務(wù)函數(shù)中直接調(diào)用HID發(fā)包函數(shù)，也是建議放到TMOS事件里運(yùn)行，原因和不要在中斷服務(wù)函數(shù)中安排TMOS事件類似：HID發(fā)包函數(shù)是走BLE發(fā)包的，就會(huì)涉及到協(xié)議棧運(yùn)行，協(xié)議棧無(wú)法預(yù)期中斷什么時(shí)候產(chǎn)生，中斷里進(jìn)行的操作可能會(huì)影響協(xié)議棧的運(yùn)行。

BLE從機(jī)代碼里可以設(shè)置最大最小連接間隔，是給定了一個(gè)范圍，連接后實(shí)際的連接間隔是要由主從機(jī)協(xié)商出來(lái)的，可以查看串口打印日志中，有一條Int xx，表明了當(dāng)前連接的實(shí)際連接間隔。為了維持BLE連接，協(xié)議棧會(huì)自動(dòng)安排喚醒，您可以對(duì)照一下該連接間隔和您串口打印喚醒的間隔是否一致。

那發(fā)送間隔具體協(xié)商過(guò)程是什么樣的？如何才能獲得最大的連接間隔來(lái)保證最小的功耗？

BLE廣播間隔和連接間隔（CH582） - SweetTea_lllpc - 博客園 (cnblogs.com)

連接間隔協(xié)商可查看該博客。

有辦法實(shí)現(xiàn)藍(lán)牙已經(jīng)連接上后更換鏈接間隔嗎，還有在TMOS中使用基礎(chǔ)的PM會(huì)有什么風(fēng)險(xiǎn)，比如基礎(chǔ)的Sleep 和 shutdown

連接成功可以調(diào)用GAPRole_PeripheralConnParamUpdateReq進(jìn)行連接間隔的協(xié)商更新，注意判斷函數(shù)的返回值確保協(xié)商成功，上面博客有做了講解，可查看。

基于藍(lán)牙功能已經(jīng)通過(guò)協(xié)議棧管理了睡眠，因此只需要管理喚醒的時(shí)間去執(zhí)行自己的任務(wù)即可。不需要再手動(dòng)的去調(diào)用Sleep等睡眠狀態(tài)。這是基于使用藍(lán)牙的基礎(chǔ)上處理的。如果不需要使用藍(lán)牙功能，則可以手動(dòng)的調(diào)用Sleep，等到需要醒來(lái)執(zhí)行藍(lán)牙或者其他功能，則可以通過(guò)GPIO或者RTC中斷喚醒。

睡眠博客可以參考：

CH573芯片Sleep說(shuō)明（RTC程序說(shuō)明） - SweetTea_lllpc - 博客園 (cnblogs.com)

好的，謝謝！

這個(gè)CallBack 方法是不是默認(rèn)不使用，我看串口打印上沒有這個(gè)的打印行

已經(jīng)在過(guò)程中重新協(xié)商最小鏈接間隔了

需要注意的是：

①進(jìn)入回調(diào)函數(shù)中才可以確保連接間隔更新成功，因此如果需要再次更新，需要在回調(diào)函數(shù)中通過(guò)tmos任務(wù)進(jìn)行調(diào)用下一次的更新；

②GAPRole_PeripheralConnParamUpdateReq需要判斷返回值是否為0，0為success；

③你上述的更新參數(shù)填寫有問(wèn)題，slavelatency和timeout這兩個(gè)值一般也不會(huì)給上圖的那么大的。

又看了遍指導(dǎo)，根據(jù)指導(dǎo)完成了對(duì)于程序的修改，但是依然沒有在串口中受到UpdateCallBack方法PRINT的條目

這是改后的更新語(yǔ)句

可以確定方法已經(jīng)正確被執(zhí)行

這是執(zhí)行的方法

可以看出來(lái)前邊的DEBUG條目已經(jīng)成功打印 然后我PRINT GAPRole_PeripherialConnParamUpdateReq方法的返回值，也確認(rèn)是0

所以我現(xiàn)在還是沒有解決更新鏈接間隔的問(wèn)題

請(qǐng)查看，如有疑問(wèn)，請(qǐng)直接發(fā)送郵件至郵箱lpc@wch.cn，我們會(huì)進(jìn)行技術(shù)支持。

剛才測(cè)試了下，我發(fā)現(xiàn)只有電腦刪除設(shè)備以后重新鏈接才會(huì)觸發(fā)設(shè)備延遲更新，但是從機(jī)掉電重新鏈接不會(huì)觸發(fā)設(shè)備鏈接參數(shù)更新

這是刪除鏈接后重新鏈接

可以看到觸發(fā)了參數(shù)更新的Callback

我寫了個(gè)TMOS循環(huán)定時(shí)任務(wù)更新參數(shù)

執(zhí)行效果如下并沒有觸發(fā)參數(shù)更新的CB

這是掉電重新鏈接的打印，也沒有重新協(xié)商參數(shù)

請(qǐng)教下，具體問(wèn)題出現(xiàn)在哪個(gè)環(huán)節(jié)，我自己沒有什么頭緒

剛才又使用CH573 試了下，也存在同樣的問(wèn)題，在測(cè)試CH573時(shí)發(fā)現(xiàn)存在同樣的問(wèn)題

只在HIDKeyBoard例程上修改了這兩行代碼，其他代碼沒有改變

郵件已回復(fù)。可以參考提供的代碼。