基于ARM9和μC/OSII的多頻道數據采集系統設計

　　3.3 針對外設的時間優化

　　針對命令掃描和解析任務，將其設置為中斷方式，在檢測到有用戶命令輸入時發生中斷，在中斷里對用戶命令進行解析、分析、提取和處理。在中斷下半部分對命令進行廣播式發布，發布到各個采樣任務函數使其立即刷新執行。因為用戶工作方式改變，命令刷新頻率并不高而且任務量不大，所以完全可以利用中斷的快速處理來實現這種功能。

圖4 顯示任務工作原理圖

　　在處理完命令掃描和采樣任務之后，影響整個系統性能的就剩下上位機和下位機顯示部分了。顯示任務工作原理如圖4所示，利用μC/OSII系統提供的消息隊列對顯示部分進行改善。分別建立兩個長度為16的消息隊列和內存塊鏈表，數據提交任務從空閑內存池中得到可用內存塊之后將本任務要顯示的數據存入該內存塊，此時該內存就變成了帶有數據的待顯示數據塊。而后將該內存塊的地址以消息的形式注冊在顯示消息隊列上。消息隊列的長度設置為16，雖然這里只有12個任務會發送消息給消息隊列，但在實時多任務程序中，各個任務的運行是隨機的，消息隊列在一段時間內得到的消息個數是個不定值，所以留出4個空位作為裕度。而且設置初始值為16的計數信號量來保護消息隊列，數據提交任務在提交數據之前先檢測該信號量，如該信號量有效就可以發送信號，如信號量無效則需等待，直到有可用信號位時方可將信號發出。在外部硬件操作端，由外部發送任務將消息隊列中的消息按照固定速率發送到外部信號線上。

　　這樣設計，消息隊列就相當于一個緩沖區，使得所有提交任務都可以向這個緩沖區發送待顯示數據，有效地避免了多個任務爭用一個外圍設備而引起的死鎖、競爭冒險等問題。同時減少了任務數量，減少了任務切換的次數，充分利用了系統時間，提高了系統性能。

　　3.4 關鍵區保護

　　多任務設計中每個任務在任何時刻都可能被其他任務打斷，必須充分考慮代碼的安全性、可重入性、可靠性、饑餓、互鎖、死鎖等情況。[3]

　　為了避免上述情況，任務間消息發送和傳遞時以及在數據采樣時對相應函數體進行關鍵區保護，在這些函數運行的時候禁止中斷和任務調度，以保證數據傳遞和數據采樣的絕對正確性和系統運行的絕對安全性。

　　4 極限頻率測定及總結

　　上位機超級終端接收到的極限頻率測試結果如圖5所示。

圖5 極限頻率測量結果

　　分別測試了高頻段、中頻段和低頻段的極限頻率，結果在CPU使用率80%~90%的情況下測定。該系統成功實現了智能化設計和優先級動態調度、系統參數動態設置等功能，達到了設計指標。