嵌入式系統上消息機制的實(shí)現

摘要：圖形用戶(hù)界面是嵌入式系統中重要部分，是用戶(hù)與系統進(jìn)行交互的樞紐，如何建立一個(gè)有效的消息機制，實(shí)現消息從用戶(hù)到系統的傳遞，以及系統對消息的處理如何再反映到圖形用戶(hù)界面是嵌入式系統開(kāi)發(fā)的重要環(huán)節。本文通過(guò)對 MiniGUI的消息機制的分析后，介紹一種簡(jiǎn)單的基于嵌入式系統的消息機制的實(shí)現方法，其相對于專(zhuān)業(yè)的 GUI中間件中的消息機制簡(jiǎn)單許多，但是也有著(zhù)完善的結構，便于系統整合在一起，非常適用于一些輕量級圖形用戶(hù)界面的嵌入式應用。

1引言

嵌入式系統，作為計算機兩大分支之一，從不同的角度影響著(zhù)人們的生活，尤其是在通訊、工控、電子等領(lǐng)域發(fā)揮著(zhù)越來(lái)越重要的作用。嵌入式設備之所以為眾多用戶(hù)樂(lè )于接受，是因為嵌入式設備有著(zhù)自然的人機交互界面，較小的尺寸、微功耗和低成本的特點(diǎn)。同時(shí)，這些特點(diǎn)也要求嵌入式產(chǎn)品設計者相應降低處理器的性能，限制內存容量和復用接口芯片，這就相應提高了對嵌入式軟件設計技術(shù)要求。如，選用最佳的編程模型和不斷改進(jìn)算法。這也正是本文的目的，提出一個(gè)消息機制實(shí)現的模型，并具有良好的可擴展性和維護性。

本文對消息機制的定義為：從底層接收用戶(hù)輸入信息(如按鍵和鼠標操作等)，經(jīng)后臺處理、記錄后反映到前臺顯示的一個(gè)機制。

2 對MiniGUI中的消息機制分析

MiniGUI下的通訊是一種類(lèi)似于 Win32的消息機制，運行在 MiniGUI-Threads模式下時(shí)，線(xiàn)程間的消息傳遞模型如下圖所示，其中的 Desktop線(xiàn)程充當一個(gè)微服務(wù)器，所有的消息在 Event線(xiàn)程獲取出來(lái)以后就會(huì )投遞給 Desktop線(xiàn)程，然后再分發(fā)到目的應用程序主窗口上面。

MiniGUI-Threads 中每個(gè)線(xiàn)程創(chuàng )建的第一個(gè)主窗口，其托管窗口必須是桌面，即 HWND_DESKTOP，該線(xiàn)程的其他窗口，必須由屬于同一線(xiàn)程的已有主窗口作為托管窗口。系統在托管窗口為 HWND_DESKTOP時(shí)創(chuàng )建新的消息隊列，而在指定非桌面的窗口作為托管窗口時(shí)，使用該托管窗口的消息隊列，也就是說(shuō)，同一線(xiàn)程中的所有主窗口應該使用同一個(gè)消息隊列。通過(guò)對 MiniGUI開(kāi)源學(xué)習版本版本 1.6.2源代碼的分析，其消息機制模型大致如下：

a) Event線(xiàn)程中的 void* EventLoop (void* data)函數通過(guò)宏IAL_Waitevent等待底層事件發(fā)生，IAL_WaitEvent實(shí)際上是調用當前系統所指定的 IAL引擎的 wait函數，收到具體的事件觸發(fā)消息后，EventLoop再調用 ParseEvent函數來(lái)解析這個(gè)事件消息， ParseEvent解析后，再往 Desktop的消息隊列中發(fā)送相應的消息， EventLoop從 ParseEvent返回后，單次循環(huán)結束，再次回到 IAL_WaitEvent，如此反復循環(huán)。

b) Desktop線(xiàn)程在隊列中收到消息后，根據消息種類(lèi)處理分別處理，再將消息發(fā)往當前活動(dòng)窗口(活動(dòng)窗口句柄__mg_active_mainwnd)的消息隊列。

c) 其它窗口線(xiàn)程中，一般會(huì )有如下格式的循環(huán)來(lái)處理消息

while (GetMessage (Msg, hMainWnd)) {

TranslateMessage (Msg);

DispatchMessage (Msg);

} GetMessage 函數從句柄為hMainWnd的窗口的消息隊列當中獲得消息，然后調用 TranslateMessage函數將某些消息如 MSG_KEYDOWN 和 MSG_KEYUP 翻譯成字符消息 MSG_CHAR ，最后調用 DispatchMessage 函數將消息發(fā)送到指定的窗口，或者理解為 DispatchMessage調用指定窗口的窗口過(guò)程，并傳遞消息及其參數。

由此可見(jiàn)，MiniGUI的消息機制是相當完整的，擴展性，健壯性都很好，很適合開(kāi)發(fā)復雜的桌面系統，但是如果在一些資源相對有限的嵌入式場(chǎng)合并且窗口數目不多，菜單簡(jiǎn)單，不需要窗口重疊，窗口移動(dòng)等應用情況下，沒(méi)有必要使用專(zhuān)業(yè) GUI中間件。在此情況下，有必要引入一個(gè)簡(jiǎn)單的消息機制，來(lái)維護系統底層事情、程序后臺菜單和前臺顯示之間的關(guān)系。

3簡(jiǎn)單消息機制的實(shí)現

3.1 消息機制結構

采用不同于MiniGUI的消息隊列的通信方式，因為簡(jiǎn)單的應用的窗口數目不多，這里的

窗口數目的含義是每一個(gè)在目標機上可能出現的系統菜單逐級顯示界面。這個(gè)消息機制的系統結構圖，如圖1所，結合圖說(shuō)明這個(gè)簡(jiǎn)單消息機制的實(shí)現過(guò)程:

后續再判斷按鍵是不是但前菜單需要的按鍵，如果不是，則此函數不會(huì )調用任何處理函數，直接返回，反之，則調用相應按鍵的處理子程序。

c) 經(jīng)判定后，如果要處理該按鍵，就進(jìn)入了相應的過(guò)程函數，每個(gè)過(guò)程函數，都有一段 refreshRoutine,這個(gè)函數的作用就是根據具體的按鍵(按鍵可能觸發(fā)轉到新的菜單頁(yè)面)，Current_win_ID,pre_win_ID,3個(gè)要素來(lái)更新 Current_win_ID，同時(shí)把原來(lái)的 Current_win_ID保存到Pre_win_ID中，這樣新的按鍵有效后，前臺顯示和后臺菜單的位置就同步了，之后調用相應的應用程序，根據應用程序返回的參數，再決定是否刷新 screenDC,即調用 GDI進(jìn)行相應區域的重繪工作。

3.2 利用2個(gè)數組來(lái)記錄所有菜單

OBJECT* WIN_OBJECT[]、MENU WIN_MENU[]這2個(gè)數組與Menu之間的關(guān)系如圖 2所示。WIN_OBJECT是一個(gè)結構體指針數組，數組的每一項，存放一個(gè)指向 OBJECT類(lèi)型的結構體數組的指針(如mainMenu[3])，這個(gè)結構體數組相當于一個(gè)菜單的作用，數組的長(cháng)度表示該菜單下，菜單項的個(gè)數，同時(shí)，ID標簽也指向這個(gè)菜單，如圖 2中 mainMenu_ID,WIN_OBJECT[mainMenu_ID]中就存放了一個(gè)指向mainMenu[]數組的指針。 mainMenu[]中的每一項指向一個(gè)具體的OBJECT結構體，可以抽象理解為指向一個(gè)按鈕。 WIN_MENU[]數組的作用是指示當前菜單下按鈕的個(gè)數，以及當前按鈕的索引和默認按鈕的索引，如WIN_MENU[mainMenu_ID]={3,0,0};表示mainMenu_ID菜單下，有3個(gè)按鈕，默認和當前按鈕都是button0。在OBJECT結構體中，還存放了該 OBJECT的事件處理函數指針。

可以看出，采用這種模型能把前臺顯示的菜單系統很直觀(guān)的表現出來(lái)，這樣，極大的方 便了后臺的維護，有著(zhù)相對可視化的優(yōu)點(diǎn)，并且具有良好的移植性能，在更換平臺時(shí)，只要考慮GDI函數的重寫(xiě)以及底層按鍵與結構體 EVENT_DESCRIPTOR注冊關(guān)系。適合于輕量級的嵌入式系統應用，不能應用于復雜的界面開(kāi)發(fā)，如需要窗口重疊，剪貼等，也恰恰印證了嵌入式系統都有著(zhù)自己特殊的應用范圍這一特殊性。

4 結 束

本文介紹的消息機制實(shí)現靈活，占用額外 ROM空間少，可以用于單環(huán)或多線(xiàn)程模式，執行效率高，同樣也有著(zhù)相對完整的結構組織。雖然不適用于大型的界面開(kāi)發(fā)，但是非常適合一些簡(jiǎn)單應用場(chǎng)合，在當前GUI功能越來(lái)越復雜，占用 ROMRAM空間越來(lái)越多的情況下，這種簡(jiǎn)單的實(shí)現方法為一些簡(jiǎn)單的界面開(kāi)發(fā)提供了一種消息機制，能有效的降低成本并保持較高的實(shí)時(shí)性。此方法已經(jīng)在基于 UC/OSII的操作系統上實(shí)現了多媒體播放器的功能。