基于DeltaOS的系統(tǒng)軟件設(shè)計

　　對于任何軟件來說，可靠性都是至關(guān)重要的。軟件的可靠性在任務(wù)內(nèi)是容易做到，通常問題都是出在任務(wù)間的接口之上。接口設(shè)計也關(guān)系到軟件可擴展性能。在多任務(wù)操作系統(tǒng)中，任務(wù)間的接口是通過同步和通信機制來實現(xiàn)的，因此同步和通信機制必須認真選取。

　　DeltaCORE提供了消息隊列(message queue)、信號量(semaphore)、異步信號(signal)、事件(event)這四種通信和同步機制。其中，消息隊列和事件機制可以同時實現(xiàn)通信和同步，信號量機制可以實現(xiàn)同步和互斥，異步信號(又叫軟中斷機制)可以實現(xiàn)同步。

　　為了滿足系統(tǒng)通信和同步的需要，可以采用兩種方案：第一種方案是信號量等同步機制實現(xiàn)同步，用全局數(shù)組或其他的共享數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)各任務(wù)間的通信，如圖5;另一種是采用消息隊列來同時實現(xiàn)通信和同步，如圖6。

　　對比兩種方案，各有優(yōu)缺點：方案一實時性強，但存在可重入性問題;方案二實現(xiàn)簡單而且可靠，但是消息隊列機制通信的實時性相對較弱。本系統(tǒng)中出站信息的突發(fā)性強，如果采用方案一，則可能導致第二個通道的數(shù)據(jù)失效或者第一個通道的數(shù)據(jù)被覆蓋;如果采用方案二雖然數(shù)據(jù)的處理延時稍大，但是數(shù)據(jù)能夠完整存儲到消息隊列中不被損壞。此外，利用消息隊列為任務(wù)提供唯一的入口，能簡化接口設(shè)計和方便功能擴展。因此，本文采用消息隊列方案，其實現(xiàn)方法如下：

　　每個任務(wù)都對應(yīng)一個消息隊列，任務(wù)只處理與之相對應(yīng)的消息隊列中的消息。對于發(fā)送方(task1)，當它需要將發(fā)送緩沖區(qū)buffer中的數(shù)據(jù)交給task2處理時，只須將buffer中的數(shù)據(jù)發(fā)送到與task2對應(yīng)的消息隊列Q2中就行了。

　　ret = delta_message_queue_send ( Queue_id[ 2 ], buffer, size );

　　其中Queue_id[2]為消息隊列Q2的ID，size為消息大小(單位字節(jié))。

　　對于接收方(task2)，將接收消息函數(shù)的等待時間參數(shù)設(shè)為永久等待，達到當消息隊列為空時阻塞任務(wù)的目的。task2的代碼如下：

　　delta_task task1()

　　{

　　delta_status_code ret;

　　…… // 定義其他局部變量

　　while(1)

　　{

　　ret = delta_message_queue_receive(

　　Queue_id[ 2 ], /*消息隊列ID*/

　　RecBuff, /*指向接收緩沖區(qū)的指針*/

　　size,/*接收消息的尺寸(單位字節(jié))*/

　　DELTA_DEFAULT_OPTIONS, /*屬性集*/

　　DELTA_NO_TIMEOUT /*等待時間*/

　　);

　　…… //完成task1功能的代碼

　　}

　　}

　　通過這種方式，任務(wù)與任務(wù)之間、任務(wù)與中斷之間的通信和同步都得以實現(xiàn)。任務(wù)的狀態(tài)轉(zhuǎn)換如圖7：

　　4 致命錯誤的防止和解決

　　通常異常是由兩種情況引起的：一種是數(shù)組越界或使用指針不當;另一種是任務(wù)棧溢出。為避免以上情況發(fā)生，數(shù)組和任務(wù)棧的大小必須設(shè)置恰當，修改數(shù)組元素的時候要保證下標是在合法范圍內(nèi)的，使用指針要特別小心。不過，DeltaOS提供了異常處理機制，用戶可以編寫自己的擴展例程，當出現(xiàn)致命錯誤的時候?qū)嵭幸欢ǖ耐炀却胧?，比如?fù)位程序整個系統(tǒng)軟件或者重新起動指定任務(wù)。

　　DeltaOS是一個強實時性的操作系統(tǒng)，通過優(yōu)化任務(wù)劃分、有效的利用中斷機制滿足了系統(tǒng)的強實時要求。利用本文提出的通信和同步方案，實現(xiàn)了任務(wù)的標準化接口，方便地進行了多次功能擴展，并且顯示了它可靠性強的優(yōu)點。