人機界面（human-computer interface），又稱用戶界面、人機交互、人機接口等，是人與機器之間傳遞、交換信息的媒介．是用戶使用計算機系統的綜合操作環境。在商品競爭中，一個應用系統的成功與否在某種程度上也取決于用戶使用界面的感受好壞，因此，人機界面的設計在應用系統的設計中有著重要的作用。嵌入式系統強調人機界面操作的實時性，簡單化，強調在特定平臺上特定應用的時間空間效率。在傳統的小系統設計中。程序設計一般采用前后臺工作方式。應用程序是一個無限的循環，循環中調用相應的函數完成相應的操作，時間相關性很強的關鍵操作（crltical operation）是靠中斷服務來保證的。因為中斷服務提供的信息一直要等到后臺程序走到該處理此信息這一步時才能得到處理．這種系統在處理信息的及時性上，比實際可以做到的要差。最壞情況下的任務級響應時間取決于整個循環的執行時間。因為循環的執行時間不是常數，程序經過某一特定部分的準確時間也是不能確定的。如果程序修改了，循環的時序也會受到影響．

實時操作系統將應用分解成多任務，簡化了應用系統軟件的設計。良好的多任務設計，有助于提高系統的穩定性和可靠性，并使系統的實時性得到保證。很多實時操作系統提供了專用函數，簡化了程序的測試。

1 系統設計

如圖1所示，人機界面系統采用小鍵盤操作的文本菜單方式，使用在嵌入式數字視頻錄像DVR（Digital Video Record）系統中。在MSP430F149上移植μC/OS—Ⅱ來獨立實現人機界面的功能，用戶通過鍵盤輸入指令，經過單片機處理后發往主系統，同時把相應信息通過專用芯片的OSD（0n Screen Display）功能顯示在監視器上；用戶根據監視器上的信息進行菜單操作，形成人與機器的交互。

把人機界面部分從主系統中獨立出來，用戶所有輸入的指令由單片機來處理，減少了主系統的工作量，使整個系統模塊化，便于開發和調試，提高了可靠性和穩定性．另外，這種人機界面設計具有通用性，便于移植到各種嵌入式系統中。本系統選用MSP430nF149單片機，是基于以下三個方面的原因：

①OSD功能需要經常刷新，并且要處理與主機部分的數據交換，要求單片機的計算速度足夠高，并且要求嵌入式系統能夠長時間正常運轉，且芯片功耗低。

②實時操作系統本身要耗費一部分內存，同時0SD功能要求建立字庫，要求內存空間足夠大，否則要外接閃存，增加設計的復雜度及成本。

③要連接鍵盤電路，需較多I／O口。

MSP430系列單片機是由TI公司開發的16位單片機。其突出特點是強調超低功耗，適合于各種功率要求低的應用；有較高的處理速度，在8 MHz晶振的驅動下，指令周期為125ns;MSP430F149具有60 KB的Flash ROM和2 KB RAM，可滿足系統程序量和數據量大的要求，可以解決因為加載實時操作系統而增加的內存需求，具有2個串行通信接口，其中一個串口用于跟主系統通信，另一個可用于控制其他外圍模塊；具有48個可獨立編程的I／O口，其中有2個具有中斷功能的8位并行端口，在設計按鍵電路時，可方便地采用中斷方式識別鍵值。

2 軟件設計與實現

2.1 實時操作系統

μC／OS—II是一個源碼開放，擁有搶占式內核，支持多任務的實時操作系統；任務被分為休眠態、就緒態、運行態、掛起態和被中斷態五種狀態，內核根據任務所處的狀態對任務作相應的處理，已經準備就緒的高優先級任務可以剝奪正在運行的低優先級任務對CPU的使用權。系統大部分代碼采用C語言編寫，與硬件相關的部分很集中，并給出了規范的接口說明，移植相當方便，可應用于目前大多數型號的8位、16位、32位CPU。μC／OS—II提供的僅僅是一個操作系統內核，對硬件系統要求很低，很適合在低端CPU上開發小系統。

將μC／OS—II移植在MSP430F149單片機上，對其進行裁減，只保留消息隊列一種任務間通信方式，利用它的任務優先級搶占機制，使人機界面很好地滿足嵌入式系統對實時性和可靠性的要求。下面詳細介紹基于μC／0S—II操作系統的程序設計。

2.2 軟件設計

本系統的軟件部分設計基于E-O模型的思想，劃分事件和目標。以有限狀態機的方式，在實時操作系統μC／OS一Ⅱ中，用狀態機把目標和事件聯系起來，實現OA （Object-Action）行為模式完成人機交互的過程，使以小鍵盤操作的文本菜單方式設計更清晰。

2.2.1 事件-目標驅動的用戶界面模型

事件-目標驅動的用戶界面模型，即E-O模型（E-vent-Object Drive User Interface Model），將人機交互活動歸結為事件與目標的相互作用．事件是人機交互活動中傳遞的信息，目標是交互活動的對象；事件引發交互活動，目標是交互活動的承受者。E-O模型基于的基本行為模式是“目標-動作”（OA），以目標為核心，具有面向對象風格。

E-O模型由四個邏輯部件組成：①設備管理模塊（device management module），提供與各種交互設備的接口，實現設備無關特性；②事件管理子系統（event Man-agement subsystem），它讀取輸入設備的輸入信息形成事件并進行統一管理，將反饋信息的事件解釋為適當的輸出指令并傳送給輸出設備；③目標管理子系統（object Man-agement subsystem），創建、裝載、保存用戶界面中各類目標，并對目標進行管理，④事件-目標管理子系統（event-object management subsystem），主要職責是實現事件與目標的整合，按適當策略控制事件在各目標結點之間流動，以形成和維持交互的過程，是整個用戶界面系統的核心。

2.2.2 有限狀態機的形式化描述

有限狀態機FSM（Finite State Machine）由狀態、事件、轉換和活動組成。每個狀態有1個狀態進入動作（entryaction）和1個狀態退出動作（exit action），每個轉換有1個源狀態和目標狀態并且與1個事件相關聯。當在源狀態時，該事件發生且觸發轉換的監護條件為真，則順序執行下列一些動作：①源狀態的退出動作；②轉換動作；③目標狀態的進入動作。

FSM可以形式化表示為1個五元組：M=（0，I，λ，S，δ，S0）。

其中，S為有限狀態集；

I為有窮的事件輸入集；

0為有窮的輸出集，

S0為初始狀態集；

δ：S×I→S，進入下一個狀態的過程；

λ：S×I→O，產生輸出的過程。

T=δUλ。T中的每個元素又可以表示為1個五元組，T=（Soure-State，Target-State，Input-Event，Con-straint，Action）。其中“Source-State”和“Target-State”分別表示T的初始狀態和目標狀態，“Input-Event”表示來自于I的輸入事件或為空，“Constramt”表示監護條件及輸入事件參數等約束，Action表示轉換執行的動作。

用軟件實現有限狀態機有兩種方法：表格法和過程驅動法。表格驅動法利用一個二維數組。該數組中的短一行與一個狀態相對應，每一列與一個輸入事件相對應，每一項則與某一狀態下對事件的處理相對應。表格驅動法適用于具有結構規則、操作簡單的有限狀態機。

過程驅動法為每一個狀態都定義一個處理過程，處理過程實現在此狀態時對事件的響應，包括輸出處理及對當前狀態值的轉換。這個過程可以用case語句區分事件，并采用相應的處理。無論采用何種方法實現FSM，當FSM收到一條消息時必須知道當前的狀態。為此，對應每一個狀態機必須能夠保存當前所處的狀態。過程法適用于實現一個具有幾種轉換和復雜操作的有限狀態機。

2.3 程序設計與實現

基于消息驅動的程序設計思想，為了保證系統的實時性，在中斷中只負責發送消息到相應的任務的消息隊列，由應用級的任務來處理，保證各個處理的時間是可確定的．主程序在消息循環中不斷地判斷各個任務的狀態，執行進入就緒態的任務。這就允許采用異步方式處理各種中斷及任務。

本系統程序中采用了兩組有限狀態機，運用消息驅動的方式來驅動狀態的變更。一組是通信任務中以串口接收數據驅動為事件對象的有限狀態機，另一組是以用戶按鍵和命令碼驅動為事件對象的有限狀態機．在實時操作系統μC／OS一Ⅱ下，整個人機界面分為三個模塊，即三個任務來實現，分別是鍵值處理模塊、與主機通信模塊和時鐘模塊。

（1）鍵值處理模塊

OSTaskCreate（KEYTaskStart，（void*）O，&TaskKey-Stk［］，7）；

先初始化所有的模塊，然后在循環中接收并處理鍵盤的輸入，Key-Process（char KeyValue）根據相應的輸入鍵值和系統所處的狀態，對菜單進行相應的操作。

State_Trans（char RxData）根據鍵值輸入事件負責調度系統的狀態，并在相應的狀態下，根據從主系統收到的信息顯示菜單。

（2）主機通信模塊

OSTaskCreate（UARTTaskskStart，（void *）O，& TaskU-artStk［］，6）；

通過消息隊列OSQPend（OS_EVENT*pevent，INTl6U timeout，INT8U*err），接受串口中斷發來的消息隊列，對其中的數據進行處理。在人機交互的過程中，需要大量的與主系統的交互，單獨用一個任務負責與主系統的通信，實現串口接收數據驅動的有限狀態機。

（3）時鐘模塊

OSTaskCreate（TimcTCk，（void*）O，&TimeTickStk［］，5）；

時鐘任務，使用單片機的時鐘中斷，可以設置各個任務需要的定時器，通過消息隊列發給需要定時的任務。

2.3.1 串口接收數據驅動的有限狀態機

為了保證通信的可靠，系統中采用停止等待協議。在發送數據前要對數據打包，接收到數據要先解包，單片機在接收主系統發過來數據包的后需要去掉通信協議字段，然后對有效數據進行正確的處理。為此，定義了一個Frame-FSM類型的數據結構，用來對接收到的數據進行處理。

typedefstruct{

byte State； ／／當前所處的狀態

byte SYM_Plas；／／轉義字符標志，若為1，表示需對當前

／／數據轉義

bytc DatoLenoth；／／數據長度

byte CheekSum；／／校驗和

byte Offset； ／／偏移地址，對應當前接收到的數據在

／／該幀中的位置

byteFrame_Data；／／幀內的有效數據

}Frame_FSM；

利用主機發送過來的消息驅動有限狀態機，串口接收數據驅動的有限狀態機包括以下幾種狀態；

①任意狀態。無論單片機原來處于何種狀態，收到字符0xaa，都表明1幀新的數據即將開始發送。此時，如果單片機處于1幀正在接收的狀態。就會丟棄原數據重新進入收到同步字符狀態。

②任意狀態（除了INIT_STATE之外）。無論單片機原來處于何種狀態．收到字符0xfc，都表明系統中出現了轉義字符。此時，將轉義字符標志置1，丟棄當前接收的數據后返回；每一次進入重建幀處理函數后，系統會首先判斷轉義字符標志是否為l。若為l，則根據當前字符進行轉義（當前字符為0x00，則轉義為Oxaa；當前字符為0x01，則轉義為Oxfc；如果為其他字符則丟棄），然后將轉義字符標志重新清O。

③INIT_STATE，初始狀態。在這個狀態下，將重建幀的偏移地址和校驗和清0，然后等待接收數據。收到起始宇符Oxaa后，將狀態轉入AA_SYN_STATE；收到其他字符都丟棄不理。

④AA_SYN_STATE，收到同步字符狀態。在這個狀態下，MCU將重建幀的偏移地址和校驗和清0，然后將狀態置為接收源地址狀態。

⑤SRC_ADDR_STATE，收到源地址狀態。此時比較源地址是否是主機地址。若是，則轉接收目的地址狀態；否則，轉初始狀態。

⑥DEST_ADDR_STATE，收到目的地址狀態。此時比較目的地址是否是MCU地址。若是，則轉接收數據長度狀態；否則，轉初始狀態；

⑦DATA_LEN_STATE，接收數據長度狀態。將數據長度備份，轉入接收數據狀態。

⑧DATA_STATE，接收正常數據狀態。將接收的數據存入接收數組REBUF中，每接收到一個數據就將對應的偏移地址加l，接收數據長度減1，并且計算此時的校驗和。當數據長度減為0時，表明l幀數據已經全部接收完畢，轉入檢驗校驗和狀態。

⑨CHECKSUM_STATE，接收校驗和狀態。將接收的校驗和與本地計算的校驗和進行比較。如果兩者相等，將狀態轉為INIT_STATE，然后對正確的數據幀進行處理，并給主系統發送一個確認幀；如果兩者不等，丟棄該幀，狀態轉入INIT_STATE，等待接收新的數據幀。

對應的狀態轉換圖（state transition diagram）如圖2所示。

2.3.2 鍵值和命令碼驅動的有限狀態機

這組有限狀態機主要依靠用戶對菜單的操作進行狀態轉換，即把鍵值和命令碼作為FSM的激勵源，其中鍵盤消息是最主要的激勵源。應用層的FSM具有多種主狀態，用戶未按鍵或者是沒有接收到新的數據幀時，狀態處于IDLE_STATE；接收到消息后，轉入對應的主狀態。然后，根據按鍵的不同或者是接收命令碼的不同，轉入對應的子狀態進行處理。任務處理完畢，再將狀態置為IDLE_STATE，按取消鍵，可回到上一級狀態。

以用戶控制云臺上下左右轉動為例，系統開始處于IDLE_STATE。若用戶按云臺鏡頭控制鍵，則進入云臺鏡頭選擇狀態，并顯示云臺鏡頭控制菜單．選擇云臺控制選項后，進入云臺方向設置狀態；選擇向上鍵，轉入向上狀態。在該狀態執行向上命令操作后，狀態重新轉入IDLE_STATE，并伴隨著輸出菜單的相應變化，按取消鍵可回到上一級云境選擇狀態。對于其他按鍵，系統全部過濾掉不作響應，狀態也不進行轉換。云臺控制的狀態轉換圖如圖3所示。

3 測 試

μC／OS—IIV2.52較以前的版本，增加了兩個系統任務一一CPU負荷監測任務與堆棧容量檢查任務。這兩個任務給程序的調試帶來很大的方便。

將系統配置常數OS_TASK_STAT_EN設為l，統計任務OSTaskStat（）就會建立。它每秒鐘運行1次，計算出當前CPU的利用率，放在一個有符號的8位整數0SCPUUsage中，精確度是l％。

μC／OS-Ⅱ內存是固定分配的，通過0STaskStkChk（）可確定每個任務實際需要的最大堆棧空間，根據測得結果合理地分配內存空間。表l是用以上函數測出的系統參數。

與MSP430單片機系統相應的調試工具Embedded Workbench，可跟蹤程序的運行。通過運行在PC機上Embedded Workberlch能夠追蹤程序中各種參數的變化，查看單片機內存的使用情況。

結 語

本系統使用μC／OS-II后，系統的總體性能有了很大提高。使用實時操作系統前。運用前后臺的程序設計方式。在需要顯示較多數據在屏幕上，同時又需要接收數據時，單片機處理不及時，可以通過調試工具WorkbenCh看到接收緩存接收的數據幀不完整，而不能正確地在屏幕上顯示數據。移植操作系統之后，工作可靠，同時系統的反應速度，即實時性有了很大提高。文中介紹的人機界面與嵌入式主系統是獨立的模塊，可以靈活地在單片機上加載控制模塊，適合應用于各種嵌入式系統中。

責任編輯：gt