基于RTX51的用戶專用鍵盤軟件設計

#define KEY 2/*任務2：按鍵碼值查詢*/

#define LIGHT 3/*任務3：串口數(shù)據(jù)處理*/

Init()_task_INIT{

Serial_init();

Os_create task(SCAN);

Os_create_task(KEY);

Os_create_task(LIGHT);

Os_delete-task(INIT);

}

以下對中斷服務程序及各個任務分別予以介紹。

3.2 中斷服務程序

用戶專用鍵盤串口接收、發(fā)送中斷服務程序流程如圖3所示。

由于中斷可能由發(fā)送控制器或接收控制器引起，因此在程序中首先要判斷是接收中斷還是發(fā)送中斷，然后分別進行處理。對于接收的數(shù)據(jù)，程序將其存入接收緩沖區(qū)，然后通知串口數(shù)據(jù)處理任務進行處理。

用戶專用鍵盤數(shù)據(jù)的發(fā)送在中斷服務程序中完成，上一字節(jié)的數(shù)據(jù)發(fā)送完畢產(chǎn)生中斷，進入中斷服務程序繼續(xù)完成下一字節(jié)的發(fā)送，而發(fā)送緩沖區(qū)中的數(shù)據(jù)由系統(tǒng)在按鍵碼值查詢?nèi)蝿罩写嫒搿：喕闹袛喾粘绦蛉缦拢?center>

3.3 串口數(shù)據(jù)處理任務(TASK_LIGHT)

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

3.4 按鍵狀態(tài)掃描任務(TASK SCAN)

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

下面給出按鍵狀態(tài)掃描任務簡化的源程序：

Scan()_task_SCAN{/*按鍵狀態(tài)掃描任務*/

…

While(1){

Key_first_scan();/*第1次掃描*/

If(Keychanged=1){

Os_wait(K_TMO，2，0)/*延時*/

Key_second_scan();/*第2次掃描*/

If(first scan=second scan){/*如果兩次掃描的按鍵狀態(tài)一致*/

os_send_signal(2);/*發(fā)送信號至按鍵碼值查詢?nèi)蝿?/

}

}

}

}

程序中，采用等待超時信號(K_TMO)來實現(xiàn)兩次掃描間的延時，這樣設計的好處是，在延時期間，由于本任務處于“等待”狀態(tài)，系統(tǒng)可以進行任務切換，使其它任務繼續(xù)執(zhí)行，從而在保證系統(tǒng)功能的前提下，提高整個系統(tǒng)的工作效率。需要注意的是，K_TMO是等待產(chǎn)生超時信號，當信號產(chǎn)生后，只是將相應的任務置上“準備好”標志位，任務并不是立即就能夠運行，任務需要等到其它任務輪流執(zhí)行，到自己的時間片后才會執(zhí)行。這樣，最后的延時效果是延時時間加上正在運行的任務的執(zhí)行時間。在用戶專用鍵盤軟件中，同時可能在運行的任務只有“串口數(shù)據(jù)處理”。由于該任務運行時間與K TMO延時時間比較少很多，因此可以忽略不計，而認為兩次掃描間的延時時間就是K_TMO的時間。假設同時運行的任務較多，并且每個任務占用的時間較長，則延時時間應該取K_TMO加上所有同時運行任務的執(zhí)行時間之和，即按鍵按下的時間必須不小于此時間，才能保證每次按鍵操作都能正確響應。

3.5 按鍵碼值查詢?nèi)蝿?TASK KEY)

按鍵碼值查詢?nèi)蝿粘绦蛄鞒倘鐖D5所示。

由于發(fā)送數(shù)據(jù)在串口中斷服務程序中完成，因此，在將數(shù)據(jù)存入發(fā)送緩沖區(qū)之前必須確認緩沖區(qū)中有數(shù)據(jù)即串口發(fā)送中斷會被再次觸發(fā)，否則只有將數(shù)據(jù)寫入串口發(fā)送緩存器SBUF直接發(fā)送。

下面給出按鍵碼值查詢?nèi)蝿蘸喕脑闯绦颍?p>Encode()_task_KEY{

…

While(1){

Os_wait(K_SIG,0,0);/*等待鍵碼查詢信號*/

Keygetcode();/*獲取鍵碼值*/

If(sendempty=1){/*判斷發(fā)送緩沖區(qū)是否為“空”*/

SBUF=keycode;/*發(fā)送緩沖區(qū)為”空”，則直接發(fā)送*/

}Else{

Outbuf[i++]=keycode;/*否則，將數(shù)據(jù)存入緩沖區(qū)，*/

/*待上一數(shù)據(jù)發(fā)送完后自動發(fā)送*/

}

}

}

4 結論

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