基于嵌入式的地鐵雜散電流監測裝置的設計

可以看到,傳統的程序是基于單任務機制的,各個模塊構成一個整體,作為一個任務運行。在實際應用中,這種程序的安全性差,只要一個系統的設計模塊出了錯誤,整個系統工作就會被打亂,只有利用看門狗進行復位。這對于比較復雜的系統,在實際運行中看門狗就會頻繁地發生復位操作。而且由于數據采集和鍵盤程序的執行頻率可能相差很多,這樣對系統的定時要求就會很高,傳統的程序流程對實時性就難以很好地滿足。
3.3.2 　基于ucosII 的系統程序流程
基于ucosII 的程序流程如圖4所示。程序中,每個模塊對應一個任務,彼此之間是并行的,但每個模塊都對應著一個不同的優先級,由操作系統進行調度運行。系統可以通過監控模塊對其他模塊的工作進行監控,從而減少看門狗的復位次數。而且通過ucosII 內核的任務調度,系統的實時性會提高很多。

3. 4 任務的劃分和構成
系統中并行存在的幾個任務按優先級從高到低依次是:顯示任務、鍵盤管理任務、輸出任務、各路數據數據采集任務和數據處理任務。系統采用靜態優先級,這樣系統的控制會相對比較簡單。
系統中的每個任務包括應用程序、任務堆棧以及任務控制塊( TCB) 三部分。任務控制塊是一個數據結構,當任務的CPU 使用權被剝奪時,ucosII 用它來保存該任務的狀態。當任務重新獲得CPU 的使用權時,任務控制塊能確保任務從被中斷的那一點執行下去。操作系統可以通過查詢任務控制塊的內容從而對任務進行管理。系統中任務的狀態有5 種:休眠態、就緒態、運行態、中斷服務和等待態。狀態之間的轉換如圖5所示。

休眠態時任務駐留在程序空間中,還沒有交給uc/ os2II 管理。當任務一旦建立,就進入就緒態。就緒態中優先級最高的任務轉為運行態。如果系統的運行導致就緒態中的一個任務優先級高于運行態的任務優先級,則系統通過調度使運行態任務喪失對CPU 的控制權轉為等待態或者就緒態,轉而運行就緒態中的那個任務。這樣就實現了任務的切換。
每個處于等待態的任務都對應一個等待時間,時間管理函數可將等待時間已過的等待態的任務轉為就緒態,這實際上也就是時鐘中斷的中斷服務程序。
3.5　任務的通信和調度
本系統中任務間的通信采用消息隊列來完成的。消息隊列是uc/ os2II 中的一種通信機制,可以使一個任務或者中斷服務子程序向另一任務發送以指針方式定義的變量。為方便易用，采用消息隊列，用于數據采集任務、數據處理任務、鍵盤管理任務、輸出任務、顯示任務之間的通信。系統通過隊列控制塊來管理消息隊列,每個消息隊列對應一個隊列控制塊。消息的存取基于優先級原則,隊列控制塊中等待任務列表內優先級任務最高的任務先從消息隊列中取消息,系統采用搶占式內核,調度函數總是保證優先級最高的就緒態任務轉為運行態。當就緒態的任務搶占CPU 時,系統執行一次中斷服務程序。當任務中的消息發送完成以及中斷返回時,系統調用調度函數,將任務從等待態轉為就緒態,這樣就緒態中任務的最高優先級就會發生變化,進而影響到運行態和就緒態間的任務切換。在本系統中,正在運行的任務需要通過消息(調用OSQPEND( ) 函數) 來等待一個事件的發生。假如該事件一直沒有出現,調用該函數的任務將被置于等待狀態(優先級最低的任務可不需要等待某個消息) 。此時下一個優先級最高的任務將立即獲得CPU 控制權。