自己在STM32上寫了個(gè)程序，移植到CH571 573上后自己寫的程序執(zhí)行沒(méi)什么問(wèn)題，1s能循環(huán) 70多次，但是每次執(zhí)行完后使用BLE HID 發(fā)送回電腦總是有延遲，串口打印的數(shù)據(jù)很快，但是BLE傳回來(lái)的數(shù)據(jù)有很大延遲，使用CH57X BLE keyboard 程序改的，把官方的Keyboard 例程循環(huán)改為跟我自己寫的程序執(zhí)行延遲一樣大以后不會(huì)出現(xiàn)這個(gè)問(wèn)題，也就是說(shuō)不是因?yàn)閿?shù)據(jù)量過(guò)大導(dǎo)致藍(lán)牙發(fā)送阻塞了，試著修改過(guò)BLE_BUF_NUM 和?DEFAULT_DESIRED_MIN_CONN_INTERVAL 還有?DEFAULT_DESIRED_MAX_CONN_INTERVAL 都無(wú)法解決問(wèn)題

UART 傳回來(lái)的數(shù)據(jù)都對(duì)著呢，而且執(zhí)行速度也足夠快，但是電腦這邊接收藍(lán)牙就有很大的延遲

藍(lán)牙發(fā)送函數(shù)如下圖，發(fā)送數(shù)據(jù)為8bytes 而且 如果數(shù)據(jù)沒(méi)變化的時(shí)候不啟動(dòng)發(fā)送程序

最大最小間隔都試著修改過(guò)，并沒(méi)有明顯的改善

代碼大概就是這么個(gè)過(guò)程，主機(jī)藍(lán)牙收到的要遠(yuǎn)遠(yuǎn)慢于串口顯示的按鍵掃描的頻率

找到原因了，CH573 的 18K內(nèi)存炸了，編譯完以后顯示占用了92%的內(nèi)存，估計(jì)是在藍(lán)牙發(fā)送階段Alloc不到內(nèi)存了，所以藍(lán)牙總是發(fā)送不了

需要注意的是，在藍(lán)牙發(fā)送數(shù)據(jù)時(shí)，會(huì)動(dòng)態(tài)申請(qǐng)內(nèi)存使用，所以需要預(yù)留足夠的RAM空間給協(xié)議棧使用。

可以嘗試預(yù)留90%左右的空間。