我們在編寫RTOS應用程序的過程中，經常會遇到這些困難，包括正確確定系統(tǒng)中有多少任務、如何設置優(yōu)先級、協(xié)調任務行為、避免常見陷阱，有時只是為了讓應用程序正常工作，而忽略一些問題。

如今，近三分之二的嵌入式系統(tǒng)使用 RTOS，而且隨著系統(tǒng)的時序要求變得越來越復雜，這個數(shù)字只會隨著時間的推移而增加。在今天的文章中，我們將研究設計基于 RTOS 的應用程序的五個最佳實踐技巧。

任務分解

首先我們可以遵循的第一個最佳實踐技巧就是使他們的 RTOS 應用程序開發(fā)成功，是使用任務分解來獲得應用程序中正確數(shù)量的任務。

有許多技術可用于分解任務，但我喜歡使用的一種對嵌入式開發(fā)人員很有效的方法是使用由外向內（outside-in）的方法。在這種方法中，開發(fā)人員遵循七個簡單的步驟：

識別并列出主要的系統(tǒng)組件；

繪制高級框圖；

標記系統(tǒng)輸入；

標記輸出；

確定一級任務；

確定并發(fā)級別和依賴項；

確定第二層任務（應用程序任務）；

在為恒溫器等物聯(lián)網(wǎng)傳感器節(jié)點執(zhí)行此過程時，最終可能會得到如下圖所示：

在這種情況下，系統(tǒng)通常有六個任務，其中一個任務監(jiān)督應用程序代碼。（根據(jù)系統(tǒng)復雜性，可以進一步分解此任務）。

選擇正確的調度算法來分配優(yōu)先級

我觀察到很多使用 RTOS 的開發(fā)人員從不花時間決定他們將如何安排他們的任務。他們通常假設 RTOS 會為他們做這件事，并且他們的任務會根據(jù)提供他們選擇的任務優(yōu)先級成功運行。

事實是，開發(fā)人員可以通過多種不同的方式來安排任務。

首先，開發(fā)人員可以使用任務響應時間來調度任務。在這些系統(tǒng)中，響應時間最短的任務應該被分配最高優(yōu)先級。

其次，開發(fā)人員可以使用一個任務執(zhí)行時間來調度任務。在這些系統(tǒng)中，執(zhí)行時間最短的任務應該被分配最高優(yōu)先級。

最后，開發(fā)人員可以使用任務周期來安排任務。在這些系統(tǒng)中，周期最短的任務優(yōu)先級最高。

只有在您選擇了調度方法之后，您才能正確設置您的任務優(yōu)先級。（我看到很多開發(fā)人員只是猜測）。

使用 RMS 驗證任務是否可調度

大多數(shù)使用 RTOS 的嵌入式系統(tǒng)中使用的調度算法是基于周期的調度，也稱為速率單調調度（Rate Monotonic Scheduling）。

多年來，人們對如何使用 RMS 正確安排任務進行了大量研究。通常，RMS 附帶了開發(fā)人員需要牢記的幾個假設。

首先，RMS 假設任務是周期性的并且它們也是獨立的。這意味著，如果您有一個非周期性任務，在分析中我們會假設為它提供一些周期性時間。

接下來，RMS 假設 RTOS 使用搶占式調度。它還假設所有任務都相等并且最壞情況的執(zhí)行時間是恒定的。

我經常發(fā)現(xiàn) RMS 非常適合對我開發(fā)的 RTOS 應用程序架構是否有意義或者我是否在錯誤的方向進行完整性檢查。

例如，我可以假設具有以下任務的系統(tǒng)的行為方式并確定它是否可以成功調度其任務：

對于使用 RMS 的系統(tǒng)，對于具有無限數(shù)量任務的系統(tǒng)，所有這些任務的 CPU 使用率必須低于 69.3%。對于上述系統(tǒng)，我們可以看到總利用率為 52%，這意味著它們應該是可調度的。

使用同步和數(shù)據(jù)流圖

在使用由外向內（outside-in）的方法確定我在應用程序中需要的所有任務后，我通常會創(chuàng)建一個同步和數(shù)據(jù)流圖。此圖的目的是：

映射系統(tǒng)中所有數(shù)據(jù)的來源

映射數(shù)據(jù)如何從其源轉移到系統(tǒng)中的任務

映射如何存儲和訪問該數(shù)據(jù)

映射如何使用該數(shù)據(jù)來生成系統(tǒng)輸出

早些時候，我以連接互聯(lián)網(wǎng)的恒溫器為例。下面是我們可能為該應用程序制作的數(shù)據(jù)流和同步圖。

如你所見，此圖不僅可以幫助我們了解數(shù)據(jù)如何在系統(tǒng)中移動，還可以幫助我們了解應用程序中所需的 RTOS 組件，例如：

隊列

流緩沖區(qū)

信號量

互斥體

如果沒有這樣的圖表，開發(fā)團隊必然會遇到開發(fā)和維護問題。

預先定義任務和消息界面接口

一旦創(chuàng)建了數(shù)據(jù)流圖，就很容易開始對應用程序進行編碼。

這無疑會在一段時間內順利進行，但我發(fā)現(xiàn)如果開發(fā)人員不花時間預先仔細定義任務和消息接口，它可能會導致返工。

雖然數(shù)據(jù)流圖通常顯示數(shù)據(jù)如何通過應用程序傳播，但它并不一定要求定義數(shù)據(jù)結構。

目標是預先檢查每個消息隊列，然后為這些消息構建結構。這很重要，因為它將定義消息的外觀，而且還將有助于任何底層模塊的接口的外觀。

例如，管理一系列閥門的任務可能需要包含以下內容的消息：

閥門 ID

閥門狀態(tài)

閥門所需的時間

再說一次，它可能會期待：

定義閥門狀態(tài)的面罩

準時清單

歸根結底，做事的方式總是不止一種，一種不一定比另一種更好。但是，在為支持任務執(zhí)行的其他模塊構建接口時，了解正在傳遞的消息將有所幫助。

結論

實時操作系統(tǒng)比以往任何時候都更多地用于開發(fā)實時應用程序。

我們在今天的文章中探討了幾個技巧，這些技巧不僅可以幫助讀者創(chuàng)建更清晰、更靈活的 RTOS 應用程序，還可以幫助他們傳達應用程序的設計意圖。希望這些技巧可以幫助你們快速開始應用程序的開發(fā)。

責任編輯：haq