1、以CH573為例，看代碼和相關(guān)說明是借用RTC的時鐘作為625us的定時，但在相應(yīng)中斷中沒有看到相應(yīng)的處理（因?yàn)槲依斫獾牟僮飨到y(tǒng)都是中斷里調(diào)用系統(tǒng)調(diào)度和tick處理，但在BLE的例中沒有看到），和tick標(biāo)記等，難道是在TMOS_SystemProcess();中不斷的中循環(huán)處理的嗎，讀取RTC的tick值嗎（感覺又不可能，這樣要不斷的判斷tick是否夠625us效率肯定低）？

2、另外用32768的時鐘來定時625us也并非整數(shù)，所以很疑惑，看了好久程序，請指點(diǎn)下，謝??！

1.tmos并不是實(shí)時操作系統(tǒng)（實(shí)時操作系統(tǒng)對ram資源消耗較大），tmos管理的任務(wù)是對實(shí)時性要求不高的任務(wù)，在空閑時處理即可，如果開發(fā)時有對時間要求高的事件需要處理，使用mcu的定時器來處理.
2.32768的時鐘來定時625us也并非整數(shù)，BLE連接對于時間要求很高，RTC計數(shù)的誤差是通過BLE內(nèi)部定時器補(bǔ)償解決，而任務(wù)本身存在誤差可不做額外處理.

感謝你的回復(fù)，如果這個625us的定時不要求太準(zhǔn)的話，那它是如保來保證跳頻的通訊的呢？

我測試了CH573的RF_PHY_Hop的范例，可能是LIB庫的原因，看不到相關(guān)跳頻部分。另外發(fā)現(xiàn) 這個范例只可以一對一的通訊。

可否修改，實(shí)現(xiàn)多對多或者一對多的跳頻通訊呢（如果能實(shí)現(xiàn)，那就漂亮了！）

內(nèi)部會有補(bǔ)償來解決RTC誤差，目前例程只支持一對一通信的跳頻。