嵌入式系統上消息機制的實現

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

1引言

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

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

2 對MiniGUI中的消息機制分析

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

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

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

b) Desktop線程在隊列中收到消息后，根據消息種類處理分別處理，再將消息發往當前活動窗口(活動窗口句柄__mg_active_mainwnd)的消息隊列。

c) 其它窗口線程中，一般會有如下格式的循環來處理消息

while (GetMessage (Msg, hMainWnd)) {

TranslateMessage (Msg);

DispatchMessage (Msg);

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

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

3簡單消息機制的實現

3.1 消息機制結構

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

窗口數目的含義是每一個在目標機上可能出現的系統菜單逐級顯示界面。這個消息機制的系統結構圖，如圖1所，結合圖說明這個簡單消息機制的實現過程:

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

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

3.2 利用2個數組來記錄所有菜單

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

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

4 結 束

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