CH579的例程里面沒有一個關(guān)于HAL_LED，HAL_KEY的例程.請問一下。是不是該HAL不支持TMOS，只建議用原生的GPIO控制

您好，LED和KEY只是GPIO的的控制，您只需要在tmos中創(chuàng)建一個事件去做對應(yīng)的處理即可。

是不是該HAL不支持TMOS，只建議用原生的GPIO控制？

答：HAL是專門為適配TMOS。參考EVT中的LED.C和KEY.C

LED、KEY都是通過一個任務(wù)，去實現(xiàn)的。

之所以BLE工程內(nèi)嵌TMOS，是因為BLE邏輯的復(fù)雜性，通過OS任務(wù)模式，可以實現(xiàn)更清晰邏輯化。

既然BLE中內(nèi)嵌了TMOS，就是MCU被TMOS全權(quán)接管分配，所有的功能，都應(yīng)該在TMOS機制下運行，即通過TMOS任務(wù)機制去實現(xiàn)，而非基于對MCU操作。

這樣才能最大程度的保證BLE框架的穩(wěn)定性。

就不能多一點案例嗎？

@TECH42?為什么藍牙串口例程ch57x_ble_uart中的串口打印也放在了和TMOS一樣的main函數(shù)主循環(huán)中，不會影響實時性嗎

?app_uart_process();這個函數(shù)并不是串口打印啊，他的操作是在查詢一個標志位，串口在中斷中接受后會置標志，查到標志后就調(diào)用藍牙將串口收到的數(shù)據(jù)通過藍牙發(fā)送給主機。

app_uart_process函數(shù)調(diào)用了app_drv_fifo_read_to_same_addr函數(shù)，往R8_UART3_THR寄存器循環(huán)寫入數(shù)據(jù)，串口1發(fā)送字符串函數(shù)UART1_SendString也調(diào)用了R8_UART1_THR寄存器，不就是打印數(shù)據(jù)嗎

那也要看什么時候會往R8_UART3_THR面寫，不是每個循環(huán)都會往里面寫，默認情況就是發(fā)送fifo里面沒有數(shù)據(jù)，是沒有往里面寫數(shù)據(jù)去發(fā)送的。

明白，確定這個操作是寫串口數(shù)據(jù)寄存器就行，以為main循環(huán)只能跑TMOS

@TECH_Hy?那SPI方式刷屏的handle可以放在主循環(huán)嗎？需要保證最多多久的執(zhí)行時間？

不建議放在主循環(huán)里去調(diào)用，最好是放在tmos任務(wù)里調(diào)用，如果事件較長還需要加大連接間隔，不然會導(dǎo)致藍牙斷開連接。

TMOS任務(wù)回調(diào)一般不超過多久的運行時間，1MS呢？

這個是沒有明確的時間的，一般建議不要超過一半的連接間隔。

連接間隔是在哪定義的，暫時沒找到

參考一下：

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