本文將深入研究劃分任務的方法，并在此基礎上，從實用的角度給出編寫基于RTX51 Tiny實時操作系統的應用軟件的指導方針。
1、任務的概念和應用軟件開發過程
在嵌入式實時多任務系統開發中，用C語言代碼表示的任務是一個無限的循環程序。任務不能有返回，不能有退出出口，但是任務可以被殺死，包括被別的任務殺死或自殺[2]。任務的概念與操作系統中的進程概念相同，一個任務是獨立的執行進程，可以與其他的并發任務競爭CPU時間。
基于RTOS的單片機應用軟件開發過程：首先是根據系統設計方案明確應用軟件的功能，然后結合RTOS的并發特性(或準并發特性)，對應用軟件要實現的功能進行大小適當的劃分，也就是把應用軟件的功能按照一定的原則劃分為若干個任務模塊，并對各個任務間的通信和時延進行仔細的確認。
2、任務劃分的原則
任務劃分有3個原則，分別介紹如下。
2.1 原則1
原則1是將同一個外設的訪問放在一個任務中。
對每個獨立的硬件(例如串行通信端口)進行操作的驅動程序段放在一個任務中。也就是說，要想對某個設備資源進行操作，只有依靠執行相應的任務來實現。這樣無論何時切換任務，都不會對任何獨立的“外設”造成影響。
這樣做能夠避免嵌入式操作系統的特殊問題——資源沖突和重入問題，而且利于系統維護與升級。各個任務之間要實現通信，可以調用os_send_signal函數及全局變量來實現。
所謂“資源沖突”，就是任務A在訪問某個資源時，恰好發生了任務切換——由任務A切換到任務B，任務B也訪問這個資源且改變了它的狀態，這樣當再次執行任務A時，就可能發生沖突或帶來不確定性。而所謂“重入”，是指假設任務A在運行某個函數，發生任務切換后，任務B也運行這個函數，這樣就會破壞任務A執行這個函數時的現場，從而可能導致任務A執行函數時結果不正確。這種問題尤其容易出現在串行接口器件的操作中，例如串口，串行的AD、DA器件等。
2.2 原則2
原則2是要通過任務分割提高系統的實時性。
在嵌入式多任務實時系統中，任務是指一個程序分段。這個程序分段被操作系統當作一個基本單元來調度。典型地，每個任務都是一個無限的循環。
RTOS本質上就是嵌入的實時內核，它負責管理各個任務，或者說是為每個任務分配CPU時間，并且負責任務之間的通信。實時內核可分為可剝奪型和不可剝奪型兩類。因此，按照所使用內核的不同，嵌入式實時系統也可分為兩類：使用不可剝奪型內核的嵌入式實時系統和使用可剝奪型內核的嵌入式實時系統。
2.2.1 長任務的定義
在RTOS中，長任務就是指整個任務的執行時間較長，超出了RTOS中其他某一個或某幾個任務的實時要求容限，而對整個RTOS的實時性構成威脅的那些任務。需要注意的是，長任務與復雜任務不能混淆，復雜任務的執行時間不一定長，簡單任務也可能會構成長任務。
2.2.2 長任務對RTOS的影響
當使用可剝奪型實時內核時，長任務由于執行的時間較長，因而更容易被高優先級的任務打斷；一旦高優先級的任務進入了就緒狀態，當前任務的CPU使用權就被剝奪了，或者說任務被掛起了，那個高優先級的任務立刻得到了CPU的控制權。這樣會出現兩個問題：一是長任務可能在一次執行的過程中被頻繁打斷，長時間得不到一次完整的執行；二是長任務被打斷時，可能要保存大量的現場信息，其目的是為了保證在高優先級任務執行完返回后，長任務能得以繼續執行。然而，這樣做要占用一定的系統資源，同時保存現場本身也是要占用CPU時間的，因此，實時性也會下降。
當使用不可剝奪型實時內核時，長任務對RTOS的影響更為明顯，因為在這種內核中，任務的響應時間取決于最長的任務執行時間。也就是說，由于長任務的存在，任務的響應時間要變長。其結果是CPU長時間停留在長任務中，其他任務得不到實時的響應，甚至根本得不到執行，系統的實時性勢必要下降。
總之，無論是使用可剝奪型內核，還是使用不可剝奪型內核，長任務都會對RTOS構成嚴重的威脅。
2.2.3 長任務問題的解決方法
解決長任務問題最有效的途徑是進行任務分割。所謂“任務分割”是指將影響系統實時性的長任務分割成若干個小任務。這樣單個任務的執行時間變短，系統的任務響應時間變短，實時性得以提高。
（1）對任務的分析與計算
當然，長任務的分割必須結合系統中所使用的內核，以及各任務對實時性的要求等情況，進行必要的分析與計算，才能保證分割的合理性和有效性，具體的步驟如下。
① 分析系統共有多少個任務，這些任務對實時性的要求有多高，求出各個任務所要求的最低執行頻率(f1，f2，…，fn)。
② 計算目前各任務的實際執行時間(t1，t2，…，tn)
③ 確定系統中的長任務。如果max(t1，t2，…，tn)≤min(1f1，1f2，…，1fn)，則此系統中不存在長任務。如果max(t1，t2，…，tn)＞min(1f1，1f2，…，1fn)，則存在長任務，而且執行時間為max(t1，t2，…，tn)的那個任務就是要找的長任務。
④ 分析此長任務是否需要分割，分析一下是什么原因導致執行的時間過長，這個時間是否能夠通過程序的優化來縮短？如果能，則不需要進行任務分割；否則，要對這個長任務進行分割。
（2）實施長任務分割
常用的任務分割的方法有以下兩種：
① 將長任務按功能分為若干個小模塊，每一個模塊構成一個小任務，每個小任務實現一種相對獨立的功能，且要保證執行時間tmin(1f1，1f2，…，1fn)。各個小任務被內核順序調用，合起來實現長任務功能。
② 有的長任務比較特殊，例如鍵盤任務和動態LED數碼管顯示任務，很難按照上面的方法把它分成若干個功能相對獨立的小模塊。這時，一般是按照方便保存現場信息的原則，將其強制分割成若干個小任務，每個小任務在min(1f1，1f2，…，1fn)時間內主動保存現場信息、放棄CPU的控制權，等到再次被內核調度時繼續執行。這種分割方法相對而言較復雜，各任務之間界限不是很明顯，看似未經分割，但實際上它卻是由多次任務中斷來完成的。
2.3 原則3
原則3是要將軟件工程中的“解耦原則”用于任務劃分。
可以采用軟件工程中的解耦原則對應用程序進行任務的劃分。任務之間的耦合是影響軟件復雜程度的一個重要因素，應該采取下述設計原則：盡量使用數據耦合，少用控制耦合和特征耦合，限制公共環境耦合的范圍，完全不用內容耦合。具體方法可參見軟件工程方面的書籍，例如文獻[3]。
