嵌入式系统上消息机制的实现（很经典的分析）

 

　　摘要：图形用户界面是嵌入式系统中重要部分，是用户与系统进行交互的枢纽，如何建立一个有效的消息机制，实现消息从用户到系统的传递，以及系统对消息的处理如何再反映到图形用户界面是嵌入式系统开发的重要环节。本文通过对 MiniGUI的消息机制的分析后，介绍一种简单的基于嵌入式系统的消息机制的实现方法，其相对于专业的 GUI中间件中的消息机制简单许多，但是也有着完善的结构，便于系统整合在一起，非常适用于一些轻量级图形用户界面的嵌入式应用。

广告插播信息
维库最新热卖芯片： SG3524BN W27E257-12 TMS320C32PCMA40 PT2257 ES1989S PBSS5350Z CA3130M HCPL-3121 IR2172 M52036SP

　　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功能越来越复杂，占用 ROM&RAM空间越来越多的情况下，这种简单的实现方法为一些简单的界面开发提供了一种消息机制，能有效的降低成本并保持较高的实时性。此方法已经在基于 UC/OSII的操作系统上实现了多媒体播放器的功能。

本文摘自http://www.dzsc.com/data/html/2009-9-7/78537.html