基于RTX51實時操作系統的用戶專用鍵盤軟件設計

摘要：隨著單片機應用的擴展，原有的編程思想難以滿足復雜多任務系統的要求，為此將操作系統引入單片機軟件設計。文章在用戶專用鍵盤軟件開發中引入PTX51實時操作系統，介紹了整個系統的任務分配，分析了各個任務的運行機制，并給出流程圖及主要程序代碼。通過采用RTX51實時操作系統，不僅提高了軟件開發效率，而且控制方案更加科學合理。
關鍵詞：RTX51；多任務；單片機；軟件設計

0 引言
傳統的用戶專用鍵盤單片機軟件采用結構化設計方法，主程序循環執行，依次完成按鍵掃描、按鍵處理、串口命令接收、串口命令處理等任務。由于任務的數量少，并且每個任務執行的操作簡單，此種設計可以使得軟件較好地滿足功能要求。但仔細分析，會發現程序一些可以改進的地方，如：執行時間短的任務不得不排隊等待執行時間長的任務的完成。此外，如果用戶的設計要求發生變化(如：專用鍵盤功能增加、按鍵數量增多、串口協議復雜化等)，原有的編程思想將很難滿足要求，程序因此無法進行移植升級而不得不重新開發。
基于RTX51實時操作系統進行單片機軟件設計，可以真正做到各任務并行執行，同時，由于程序結構更加科學合理，可以方便地實現修改升級，以滿足功能較多的設計要求。

1 用戶專用鍵盤簡介
用戶專用鍵盤多使用在工業控制場合，它由按鍵和指示燈組成，對外采用RS232接口，當某個按鍵按下時，鍵盤將命令(碼值)發送計算機，同時，鍵盤接收來自計算機的命令(碼值)點亮(熄滅)某個指示燈，以指示系統工作狀態，從而實現快速人機交互。用戶專用鍵盤硬件原理框圖如圖1所示。

圖中，可編程邏輯芯片實現單片機輸出接口擴展，其內部包含多個輸出鎖存器。工作時，單片機輸出的地址信號經可編程芯片內部譯碼器譯碼產生片選信號，使能不同的輸出鎖存器，將數據信號輸出控制各個指示燈的亮／滅。

2 RTX51實時操作系統介紹
RTX51是德國Keil公司開發的一種應用于MCS51系列單片機的實時多任務操作系統，它有兩個版本，RTX51 Full和RTX51 Tiny，本文采用
RTX51 Tiny進行軟件設計。RTX51 Tiny是一個很小的內核，完全集成在Keil C51編譯器中，它可以很容易地運行在沒有擴展外部存儲器的單片機系統上，并且僅占用800字節左右的程序存儲空間。
RTX51 Tiny允許最大16個任務循環切換，在實現上，它采用時間片輪轉算法，系統每次調度時，把CPU分配給一個就緒的任務，并令其執行一個時間片，構成微觀上輪流運行、宏觀上并行執行的多任務效果。RTX51 Tiny支持任務間的信號傳遞，還能并行地利用中斷功能。
RTX51 Tiny的用戶任務主要具有以下幾個狀態：
·運行(RUNNING)：任務正處于運行中。同一時刻只有一個任務可以處于“RUNNING”狀態。
·準備好(READY)：等待運行的任務處于“READY”狀態。在當前運行的任務退出運行狀態后，就緒隊列中的任務根據調度策略被調度執行，進入到運行狀態。
·等待(BLOcKED)：等待一個事件的任務處于“BLOCKED”狀態。如果等待的事件發生，則此任務進入“READY”狀態，等待被調度。
RTX51 Tiny內核用以下事件進行任務問的通信和同步：
·超時(TIMEOUT)：由OS-wait函數調用引發的時間延時，持續時間可由定時節拍數確定。帶有TIMEOUT值調用OS-it函數的任務將被掛起，直到延時結束，才返回到“READY”。
·間隔(INTERVAL)：由OS-wait函數調用引發的時間間隔，其間隔時間可由定時節拍數確定。帶有INTERVAL值調用wait函數的任務將被掛起，直到間隔時間結束，然后返回到READY狀態。與TIMEOUT不同的是，任務的節拍計數器不復位，典型應用是產生時鐘。
·信號(SIGNAL)：系統定義的位變量，可以由系統函數置位或清除。可以調用OS-wait函數暫停一個任務并等待從另一任務發出的信號，這可以用于協調兩個或更多的任務。如果某個任務在等待一個信號并且信號標志為0，則在收到這個信號之前，這個任務將一直處于掛起狀態。如果信號標志已經被置1，則當任務查詢信號時，信號標志會被清除，任務將可以被繼續執行。

3 用戶專用鍵盤軟件設計
3．1 任務分配
根據前面對用戶專用鍵盤功能的描述，它主要實現以下兩個功能：
(1)按鍵處理；
(2)串口數據處理。
其中功能(1)又可細分為以下三個任務：
任務1：按鍵狀態掃描；
任務2：按鍵碼值查詢；
任務3：串口發送；
同樣，功能(2)也可細分為以下兩個任務：
任務4：串口接收；
任務5：串口數據處理；
以上兩個功能需要并行運行，而內部的子任務之間為前級驅動后級的關系，在程序實際運行過程中，功能二(2)的任意子任務可能與功能(1)的任務1或任務2或任務3處于同時并行運行狀態，鑒于此，需要在程序設計時創建5個子任務。
采用時間輪詢的方式決定了某個任務在執行完時間片后，在下一次執行前需要等待固定的時間，這個時間與系統的任務數及每個任務的執行時間密切相關，為避免數據丟失，串口接收任務應及時讀取接收緩存器中的數據。由于中斷處理過程與正在運行的任務是相互獨立的，即中斷處理過程在RTX51系統內核之外和任務切換規則沒有關聯，因此可以在串口中斷服務程序中完成串口接收任務。另外，串口發送時要求將整個按鍵碼值數據包一次性發送完畢，如果將串口發送過程在中斷服務程序中完成，在SBUF緩存器發送完一個字節后觸發串口發送中斷標志，再次進入中斷服務程序繼續下一字節數據的發送，則可以方便地實現上述要求。根據以上分析，串口接收、串口發送兩個子任務的功能在中斷服務程序中完成，將系統子任務的個數由5個減少為3個，調整后的任務分配如下：
任務1：按鍵狀態掃描(TASK SCAN)；
任務2：按鍵碼值查詢(TASK KEY)；
任務3：串口數據處理((TASK LIGHT))；
中斷服務程序：串口接收、發送。
任務間信號關系如圖2所示。

如圖，任務1在檢測到按鍵狀態變化后向任務2發送信號，任務2隨后由等待狀態進入“準備好”狀態，在本任務的下一個時間片，任務2開始進行指定位置按鍵的碼值查詢，然后通過串口完成碼值發送。
同時，串口數據通過中斷服務程序接收，串口數據接收后即發送信號給任務3，使后者進入“準備好”狀態，并在下一個時間片到來后進行數據處理。
以上三個任務中，任務l始終處于“運行”或“準備好”狀態，任務2、任務3大多數時間處于“等待”狀態，任務2、任務3分別在接收到按鍵狀態掃描任務、中斷服務程序的信號后被“喚起”。另有任務0，負責創建任務1、2、3，然后刪除自己。任務0簡化程序如下所示：
#define INIT 0／*任務0：初始化及創建*／
#define SCAN 1／*任務1：按鍵狀態掃描*／
#define KEY 2／*任務2：按鍵碼值查詢*／
#define LIGHT 3／*任務3：串口數據處理*／
Init()_task_INIT{
Serial_init()；
Os_create task(SCAN)；
Os_create_task(KEY)；
Os_create_task(LIGHT)；
Os_delete-task(INIT)；
}
以下對中斷服務程序及各個任務分別予以介紹。
3．2 中斷服務程序
用戶專用鍵盤串口接收、發送中斷服務程序流程如圖3所示。

由于中斷可能由發送控制器或接收控制器引起，因此在程序中首先要判斷是接收中斷還是發送中斷，然后分別進行處理。對于接收的數據，程序將其存入接收緩沖區，然后通知串口數據處理任務進行處理。
用戶專用鍵盤數據的發送在中斷服務程序中完成，上一字節的數據發送完畢產生中斷，進入中斷服務程序繼續完成下一字節的發送，而發送緩沖區中的數據由系統在按鍵碼值查詢任務中存入。簡化的中斷服務程序如下：

3．3 串口數據處理任務(TASK_LIGHT)
中斷服務程序只處理串口緩存器SBUF的讀取或寫入，數據一旦接收完畢即存入緩沖區，并在專門的任務中進行處理。在多任務系統的用戶專用鍵盤程序中，串口數據處理任務在創建后即被“掛起”，此時該任務處于“等待”狀態，不占用任何時間片，只有當任務接收到“喚起”信號后才繼續執行。本程序中“喚起”信號來自中斷服務程序。由于中斷處理過程可以同RTX51任務互發信號或交換數據，因此，中斷服務程序在接收到數據后立即發送信號量給串口數據處理任務，使后者處于“準備好”狀態，當下一時間片來到時，串口數據處理任務繼續執行，完成數據解析及控制指示燈等操作。由于該任務為循環操作，當所有接收的數據處理完畢后，任務再次進入“等待”狀態，等待下一次串口數據接收后的處理。圖3中，斜體部分即為中斷服務程序發送信號至串口數據處理任務的過程。串口數據處理任務的簡化程序如下：

3．4 按鍵狀態掃描任務(TASK SCAN)
按鍵狀態掃描為一個循環執行的任務，程序通過不斷地讀取單片機IO口的值獲取每個按鍵的當前狀態，然后將當前狀態值與存儲在內存中的上一次狀態值進行比較，通過比較結果判斷該按鍵狀態是否發生變化。為消除按鍵按下時抖動造成的多次狀態變化，在掃描到某個按鍵狀態發生改變后，延時一段時間后進行第二次掃描，如果兩次掃描結果相同則認為該按鍵狀態確實發生改變，并轉入下一步處理。按鍵狀態掃描任務流程如圖4所示。

下面給出按鍵狀態掃描任務簡化的源程序：
Scan()_task_SCAN{／*按鍵狀態掃描任務*／
…
While(1){
Key_first_scan()；／*第1次掃描*／
If(Keychanged=1){
Os_wait(K_TMO，2，0)／*延時*／
Key_second_scan()；／*第2次掃描*／
If(first scan=second scan){／*如果兩次掃描的按鍵狀態一致*／
os_send_signal(2)；／*發送信號至按鍵碼值查詢任務+／
}
}
}
}
程序中，采用等待超時信號(K_TMO)來實現兩次掃描間的延時，這樣設計的好處是，在延時期間，由于本任務處于“等待”狀態，系統可以進行任務切換，使其它任務繼續執行，從而在保證系統功能的前提下，提高整個系統的工作效率。需要注意的是，K_TMO是等待產生超時信號，當信號產生后，只是將相應的任務置上“準備好”標志位，任務并不是立即就能夠運行，任務需要等到其它任務輪流執行，到自己的時間片后才會執行。這樣，最后的延時效果是延時時間加上正在運行的任務的執行時間。在用戶專用鍵盤軟件中，同時可能在運行的任務只有“串口數據處理”。由于該任務運行時間與K TMO延時時間比較少很多，因此可以忽略不計，而認為兩次掃描間的延時時間就是K_TMO的時間。假設同時運行的任務較多，并且每個任務占用的時間較長，則延時時間應該取K_TMO加上所有同時運行任務的執行時間之和，即按鍵按下的時間必須不小于此時間，才能保證每次按鍵操作都能正確響應。
3．5 按鍵碼值查詢任務(TASK KEY)
按鍵碼值查詢任務程序流程如圖5所示。

由于發送數據在串口中斷服務程序中完成，因此，在將數據存入發送緩沖區之前必須確認緩沖區中有數據即串口發送中斷會被再次觸發，否則只有將數據寫入串口發送緩存器SBUF直接發送。
下面給出按鍵碼值查詢任務簡化的源程序：
Encode()_task_KEY{
…
While(1){
Os_wait(K_SIG,0,0)；／*等待鍵碼查詢信號*／
Keygetcode()；／*獲取鍵碼值*／
If(sendempty=1){／*判斷發送緩沖區是否為“空”*／
SBUF=keycode；／*發送緩沖區為”空”，則直接發送*／
}Else{
Outbuf[i++]=keycode；／*否則，將數據存入緩沖區，*／
／*待上一數據發送完后自動發送*／
}
}
}

4 結論
實踐證明，在引入RTX51 Tiny實時操作系統后，軟件開發周期縮短，程序結構更加清晰，系統實時性和并行性大大增強，開發出的程序具有較高的可維護性和可移植性。