引言

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

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

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

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

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

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

1.1 任務管理內核（QK）

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

1.2 基礎框架平臺

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

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

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

1.3 狀態(tài)機部件（QEP）

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

1.4 跟蹤調試器（QSPY）

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

2 QP 到TMS320LF2407 的接口移植

QP存在C和C++版本?；?a href="http://www.asorrir.com/soft/data/21-24/" target="_blank">C語言版本的精簡版QP平臺的代碼量可以在4 KB左右，可以輕易的放入到大多數(shù)的小規(guī)模CPU的片上存儲器中。并且該平臺的實現(xiàn)原理如上節(jié)所述可以使用C編譯器實現(xiàn)[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 完成了狀態(tài)機的實現(xiàn)機制。配置和移植QEP需修改qep_port.h頭文件中關于各種數(shù)據(jù)類型和主要參數(shù)的定義。其中主要的有Q_ROM,Q_ROM_VAR 和QEP_SIGNAL_SIZE 三個宏定義。Q_ROM 宏是用來定義常變量到程序存儲區(qū)域的，比如使用較大的表或數(shù)組等常數(shù)時不希望占用RAM資源時，將其定義在程序區(qū)，可以使用Q_ROM宏。定義方法根據(jù)不同的編譯器而不同，比如在Keil C51 中Q_ROM 被定義為code 關鍵字。

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

2.2 QF的接口移植

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

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

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

2.3 QK的接口移植

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

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

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

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

2.4 QS 的接口移植

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

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

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

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

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

其中分為4個狀態(tài)，正常工作時系統(tǒng)在程控模式和正常模式間轉換，觸發(fā)信號為程控結束和E5.4 信號。

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

3.2 軟件源程序的生成

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

3.3 控制器軟件的測試結果

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

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

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

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

4 結論

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

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