我有一個任務，基本上是一個定時器;所以它進入睡眠狀態，應該週期性地喚醒。所以計時器任務睡了10毫秒。但是現在發生的情況是，它在醒來時不一致，不能依靠正確地喚醒。Linux RTOS睡眠（） - 喚醒（）定時任務
事實上，在我的跑步中，睡眠時間有很大差異。有時覺醒時可能會有1-2毫秒的變化，並且很少有時間不會再回來。這是因爲內核調度程序將所有睡眠和等待任務放入一個隊列中，然後在輪詢查看誰將被喚醒時，我認爲這是循環法。所以有時候任務會在調度器再次輪詢時失效。有時，當有中斷時，ISR獲得控制權並延遲計時器醒來。
處理這類問題的最佳解決方案是什麼？
（附加細節：任務是用於無線網絡的MAC定時器; RTOS是U velOSity微內核）
您應該使用由OS上而不是依賴於調度器提供的計時器API。這裏是對timer API for Linux drivers的介紹。
只需要上傳@Micea，我發現了開發一個用戶空間應用程序的相同事情，該應用程序必須定期在UART總線上發送一些數據。當定時器結束時，我使用一個OS定時器來觸發信號。該信號作爲中斷，在您的應用程序中，您只需在收到信號時運行任務。這顯着改善了我的事情。我從一個〜3ms波動到小於1ms波動。 – Eric
如果你需要硬核時間，操作系統調度程序可能不夠好（正如你找到的那樣）。
如果可以的話，使用單獨的定時器外設，以及使用它的ISR做少，你可以用（時間戳一些關鍵數據，設置例如一些標誌）和然後脫身讓你更高的抖動常規利用那些數據，並保證其時間安全性較低。
謝謝。我可能會按照您的建議使用外設。 – mane
Linux不是一個RTOS，這可能是你的問題的根源。
您可以使Linux更適合以各種方式和各種程度的實時使用。有關某些方法的信息，請參閱A comparison of real-time Linux approaches，並對可預期的實時性能級別進行評估。
RTOS在哪裏出現這個問題？你在最後提到了u-velosity，但它似乎完全不相關的問題在哪裏沒有提及。 – Clifford