引言

隨著高級編程語言和操作系統在越來越多種類的CPU構架上的應用，系統應用程序變得越來越大，越來越復雜。并且實際應用大多對于程序的設計周期、可靠性都具有很高的要求。基于傳統的嵌入式實時操作系統的軟件設計，雖然可使程序的實時性能得到提高，但是并行程序設計過程中存在著更多的競爭狀態，而且這些競爭狀態極難被發現。如何能夠找到一種符合軟件工程學的程序設計方法成為每個嵌入式軟件工程師所面臨的問題。

傳統的實時操作系統雖然可以完成任務管理，但是往往代碼量較大，任務切換要求復雜，完全摒棄編譯器提供的程序調用機制，采用任務堆棧機制，接口程序設計要求高，實現任務切換時占用資源較大，不適合應用于8位和16位總線構架的CPU上。

另一方面，基于UML 的實時框架程序設計方法對于當今的高復雜性、短開發周期的商業環境來說變得越來越重要。主要是因為UML 語言是可執行的，所以根據UML 建立的系統行為模型可以生成可執行代碼，從而節約了從抽象模型到手工編寫可執行代碼的費時、費力的工作量。但是所有的UML 代碼生成工具是為類似PC上應用而設計的，不適合應用于中小型的CPU,且售價昂貴。

如果將RTOS的實時性與UML模型設計的直觀性、安全性和便捷性相結合，應用于中小規模的CPU 芯片無疑會給深度嵌入式系統開發帶來更多的手段。

1 實時UML 框架程序設計平臺（QP）簡介

QP是使用實時搶占式任務管理內核、基于UML狀態圖的軟件設計方法的輕量級軟件平臺，是一種新式操作系統。QP軟件平臺結構如圖1所示由以下4個部件組成。

1.1 任務管理內核（QK）

QK也采用了類似其他商業內核的優先級的搶占機制以保證關鍵任務得到實時執行。但是QK 實現搶占的原理有別于任何一種操作系統。QK采用的是Moore狀態機的“運行到結束”的機制，因此當系統還在忙于處理前較低優先級事件時，當較高優先級的事件到來時，系統將新事件存儲在消息隊列中，直到低優先級事件完成后，再執行新事件。QK 的實現原理不同于傳統RTOS的堆棧操作，僅使用C 語言編譯器的中斷服務程序（ISR）機制就可完成。也就是QK的移植完全不需要插入額外的匯編語句。所以，任務切換時沒有額外的開銷，執行速度快，相當于子程序調用。當然如果使用其他RTOS 的任務管理功能也能代替QK,稍候在QP 到TMS320LF2407的接口程序設計部分介紹。

1.2 基礎框架平臺

該框架平臺完成了驅動事件管理功能、狀態機架構管理和實時任務管理功能。

實時UML框架序設計平臺（QF）中任務是由能實現輕量級UML狀態機和用來接收觸發事件的消息隊列組成。因此基于實時UML框架的任務具有UML狀態機的特點。QF 將任務分為激活狀態和休眠狀態，QF 根據觸發事件和任務優先級對其進行管理。實際工作時任務間采用異步的事件發送和接收機制進行通信。任務使用消息隊列接收其他活動對象的事件消息；同時，不同任務產生的事件也會利QF投送給其他訂閱該消息的任務。對于觸發事件的交換，排隊，收集，銷毀等工作則由QF統一完成。可見，任務間通過QF框架進行間接通信，實現了事件松耦合。因此，基于QF的程序設計可以采用模塊化的設計方法，給設計過程中方案的修改和設計后期的軟件維護提供了極大的方便。正像使用UML 的自動設計工具軟件進行程序設計的過程一樣，使用QF的程序設計也遵循以下過程：使用UML語義進行模型設計，根據QP平臺代碼轉換方法將UML模型轉化為源代碼。

總之，基于QF的程序設計實現了可視化程序設計和“自動”代碼生成的目的；另外，在嵌入式系統中也可以將QF當作為一個軟件總線，將QF的接口移植到其他OS之上，以隱藏下層硬件和軟件的差異。

1.3 狀態機部件（QEP）

上節提到的QF任務的狀態機的特性是由狀態機部件（QEP）完成的。QEP是一個簡化的輕量級的UML狀態機部件，實現了狀態機的狀態轉換觸發事件響應等功能。QEP提供了兩種狀態機類型：層次化狀態機（HSM）和平面狀態機（FSM）。

1.4 跟蹤調試器（QSPY）

QSPY 使用緩存機制采集系統內運行狀態，事后在空閑任務時再編碼輸出，再有在整個QP 平臺中QSPY調試插件有機的與系統關鍵運行環節有機的結合在一起，因此基于QSPY的調試可以獲得更多的系統的信息的同時又不會過多地干擾程序的正常運行。在這一點上比傳統RTOS中的跟蹤調試器更領先一步。

2 QP 到TMS320LF2407 的接口移植

QP存在C和C++版本。基于C語言版本的精簡版QP平臺的代碼量可以在4 KB左右，可以輕易的放入到大多數的小規模CPU的片上存儲器中。并且該平臺的實現原理如上節所述可以使用C編譯器實現[4],因此移植工作量極少，僅需幾十行的C語言程序就可完成。顯然在諸如TMS320LF2407 的中小型的CPU 上更適合使用基于C 的版本。QP 移植主要的工作集中在改寫qep_port.h,qf_port.h,qf_port.c,qk_port.h 和qs_port.h 這4 個文件。

2.1 QEP的接口移植

QEP 完成了狀態機的實現機制。配置和移植QEP需修改qep_port.h頭文件中關于各種數據類型和主要參數的定義。其中主要的有Q_ROM,Q_ROM_VAR 和QEP_SIGNAL_SIZE 三個宏定義。Q_ROM 宏是用來定義常變量到程序存儲區域的，比如使用較大的表或數組等常數時不希望占用RAM資源時，將其定義在程序區，可以使用Q_ROM宏。定義方法根據不同的編譯器而不同，比如在Keil C51 中Q_ROM 被定義為code 關鍵字。

Q_ROM_VAR 宏用來定義如何采用指針類型取程序存儲器變量。QEP_SIGNAL_SIZE 宏用來定義信號寬度，通常為1,2或4.針對TMS320LF2407的硬件結構特點定義了8位、16位和32位有符號和無符號數的類型。

2.2 QF的接口移植

QF 的移植主要集中在對于狀態機和任務管理方面。在qf_port.h 中根據實際的軟件需求修改狀態機實現相關的定義，例如觸發事件的類型、事件隊列的深度和事件緩存的容量。QF中事件初始位置存放在事件緩存區中，所有的任務間的事件傳遞使用指針方式進行，從而有效地減少了事件傳遞對內存的開銷。任務管理方面定義了最大任務數、中斷嵌套相關的定義以及任務切換的機制。

在pf_port.c中需要編寫有關諸如QF平臺開始和退出代碼，如無特殊需要這些函數可以使用空函數代替。

QP平臺中對于程序的運行關鍵位置使用了斷言手段進行約束，在平臺運行異常時會給出診斷信息。在pf_port.c 的Q_assert_handler（）函數可以返回平臺錯誤信息。

2.3 QK的接口移植

QP平臺的任務調度機制在QK中完成。因此QK的移植需要根據TMS320LF2407 的編譯工具進行接口函數的設計。所有調度相關的定義在qk_port.h 頭文件中。其中主要的是中斷相關的定義，如：開關中斷的機制和中斷響應程序的進入和退出機制等。

QK 中使用QK_INT_KEY_TYPE,QK_INT_LOCK（key_），QK_INT_UNLOCK（key_）三個宏接口定義了中斷開關機制。其中QK_INT_KEY_TYPE 定義了中斷嵌套時中斷優先級傳遞參量類型。QK_INT_LOCK（key_）定義了關中斷的機制，QK_INT_UNLOCK（key_）定義了開中斷的機制。在TMS320LF 因為在TMS320LF2407 的C 編譯器中沒有直接對ST0、ST1 寄存器進行操作的方法，此處使用嵌入匯編實現中斷使能和中斷禁止功能。還有，在TMS320LF2407 中具有中斷優先級管理器，因此中斷傳遞參數類別QK_INT_KEY_TYPE在本移植中不用定義。

QP 中中斷服務程序相當于最高優先級的任務，因此中斷的進入動作QK_ISR_ENTRY（）和退出動作QK_ISR_EXIT（）需要特殊規定：QK_ISR_ENTRY（pin,ISR_PRIO）：首先是，將當前QK 優先級保存到變量pin上；然后將當前QK的優先級ISR_PRIO改變為最高優先級別；最后使能中斷。QK_ISR_EXIT（pin）中斷服務程序退出動作的過程是：關中斷，清中斷寄存器結束中斷標記，從變量pin中恢復以前的優先級，調用QK的任務切換函數進行任務調度。

需要注意，TMS320LF2407 中斷有2 種類型：一種由事件管理模塊管理，不需要使用程序清中斷標志位，如定時器，計數器，PWM 等設備；另一種需要任務清中斷標記，如串行外設接口（SPI）、串行通信接口（SCI）、CAN 總線等。所以在中斷退出時需要分別處理，一般在BSP中進行。

2.4 QS 的接口移植

QS 完成了軟件系統運行信息的收集和輸出功能。

QS移植需要修改qs_port.h文件。其中定義了系統信息緩存區的深度，定義了在空閑時系統信息的輸出方式等。

3 基于QP 的航天相機控制器控制軟件的實例通過上節所述的構建過程QP 平臺被移植到了TMS320LF2407上，下面通過某航天相機控制器的控制軟件的設計實例說明基于QP的軟件架構設計過程和實際運行結果。

3.1 基于QP的航天相機控制器的軟件設計

基于QP 平臺的軟件設計過程完全采用UML 的圖形可視化方法。使用用例圖分析軟件任務、需求。使用類圖描述軟件架構。使用活動圖或順序圖描述軟件結構中的對象間的消息交換細節。使用順序圖與狀態圖描述軟件系統對象間的行為轉換。如圖2中描述了航天相機控制器軟件總體架構的狀態轉換圖。

其中分為4個狀態，正常工作時系統在程控模式和正常模式間轉換，觸發信號為程控結束和E5.4 信號。

在正常模式內部又有工況參數輪詢和攝像2種模式，通過相應的觸發信號系統在兩種狀態間轉換。另外E5.1.1到E5.1.7信號為內部轉換觸發信號。

3.2 軟件源程序的生成

在QP中有關狀態機的所有的要素，如狀態、層次狀態、狀態轉換、輸入事件觸發和輸出事件觸發均可以對應為固定的源代碼，在將活動對象轉化為源代碼時幾乎無需編程人員的參與。例如，對于狀態機中的狀態，QP中使用帶有事件參數指針的函數來表示，其返回值指向另一個QP狀態。對于信號的傳遞采用指針消息隊列來表示。

3.3 控制器軟件的測試結果

由于使用了QS動態調試手段，所以可以在最為接近全速運行的狀態下收集軟件運行信息。如圖3所示控制器采集模擬量工況參數場景的實測各個觸發事件發生的時間信息，時間刻度為1 μs.

如圖3中所示模擬量遙測任務在t1時刻執行，采集系統內的模擬量參數。采集完成后在t2時刻向系統“發布”數據信號量。在t4時刻“訂閱”了數據信號的數據合成任務得以執行。在數據合成任務以某種方式對數據打包編碼后，在t5 時刻向系統“發布”打包后的數據消息。最后通訊任務在t6時刻，將打包數據通過數據鏈路輸出。對于模擬遙測任務，t1 為任務執行的起始時刻，t3 為任務結束時刻，任務執行時間可由下面表達式（1）來描述。

根據上面的測量方法可以統計一個軟件運行周期內所有任務的執行時間，下表是本相機控制器軟件在2 s的運行周期內，常規工況下，所有任務執行時間的統計結果。

通過上表可見，QP 平臺完成了軟件中各個任務的管理工作，但是QP 平臺對于系統資源的占用時間極少。另外采用速率單調調度[1]（RMS）算法可以看到本應用軟件是完全可調度系統。通過上面講述的工作后，證明整個系統已經能夠正常運行，移植成功。

4 結論

綜上，QP下的程序設計完全是基于可視化的UML狀態圖方式，因此提高了程序設計的效率，縮短了設計周期，并且減少了不確定的、無法預測的狀態從而加強了軟件的安全性；QP 的實現原理有別于傳統的RTOS,因此QP具有緊湊的代碼結構，代碼量小，QP的代碼量非常少，即使是在所有的功能都被使能的情況下也只有4 K左右[1],更適合于深度的嵌入式系統。

因此，在完成了QP 平臺在TMS320LF2407 上的構建的同時也證明了基于實時UML狀態機的應用軟件是完全可以在中小型CPU上運行的。