許多 RTOS 內核在設置內核的周期性滴答中斷方面為開發人員提供了很大的靈活性。不幸的是，這種靈活性有時會導致混亂。似乎是許多問題根源的刻度的一個可配置方面是頻率。我將嘗試消除與頻率有關的常見神話，并嘗試解釋建立系統滴答率所涉及的基本權衡。

也許由于其他內核或特定硬件平臺中存在的限制，似乎有一個廣泛的共識，即 μC/OS-II 和 μC/OS-III 限制了應用程序代碼可用的滴答頻率范圍。然而，內核本身應該能夠支持在給定 MCU 上可行的任何滴答頻率。我已經看到應用程序以遠低于 100 Hz 的滴答率運行，而在頻譜的另一端，則遠遠超過 1 kHz。

如果內核對系統的滴答頻率沒有任何特殊影響，那么在設置此參數時應該考慮哪些因素？除了會產生滴答聲的外圍設備施加的限制之外，您的主要關注點應該是開銷和分辨率。使用相對較高的頻率，您將能夠以比其他方式更小的增量建立延遲，但是您將為此能力付出代價，增加的開銷是以處理滴答的 CPU 時間的形式。較低的頻率會減少滴答處理時間，但當然也會限制系統延遲的分辨率。例如，在每 10 毫秒發生一次滴答的系統中，內核將無法提供低至 1 毫秒的延遲。

為了在開銷和分辨率之間取得適當的平衡，您需要考慮硬件平臺的功能和應用程序的時序需求。以 μC/OS-II 或 μC/OS-III 為例，在以 300 MHz 運行的 32 位處理器上，任一內核每秒處理 1，000 個滴答所需的開銷可能不會超過 CPU 周期的 1%。但是，具有 24 MHz 時鐘的 16 位 MCU 可能是另一回事。同樣，僅使用時間延遲來輪詢按鈕按下的應用程序在 50 毫秒的滴答分辨率下可能不會遇到任何問題，但對于截止日期較緊的任務來說，這樣的設置可能是不可接受的。

關于最后一點，重要的是要注意，滴答聲可能不是解決系統中所有延遲的最佳解決方案。例如，如果您想每 500 μs 從 A/D 轉換器讀取數據，那么最好的方法可能是讓您的轉換器由中斷驅動并使用定時器觸發轉換（與滴答中斷無關的定時器） 。 換句話說，基于滴答的函數旨在用于嚴重延遲——例如，負責大約每 10 毫秒輸出一條消息的狀態任務可能需要這樣——并且你應該轉向專用的硬件定時器，當需要更準確的延遲。我將在第 3 部分中提供與此主題相關的更多詳細信息，其中我解釋了內核節拍的另一個有時令人困惑的方面：優先級。

審核編輯：郭婷