MiniGUI在HDTV SoC平台上的移植
1．引言：
嵌入式系统功能的日益强大使得在嵌入式产品中包含图形界面功能成为一种趋势。但是嵌入式系统有着面向特定应用、实时、高效等特点，对系统资源的利用受自身条件的限制，对GUI有着轻型，高可靠性，高稳定性等要求。
高清数字电视解码平台HDTV SoC是由上海交通大学自行研究开发的，以数字电视机顶盒为应用背景的嵌入式单片系统。在硬件平台构建和操作系统移植的基础上，系统对友好的界面提出了更高的要求。在有限的系统资源和高效的实时性能等条件约束下，如何为该平台提供GUI的支持成为了一个难点。
MiniGUI是一种面向实时嵌入式系统的轻量级图形界面支持系统，具有小巧，高效，可移植性好等特点。针对HDTV SoC平台的硬件特点和MiniGUI体系结构的特性，本文提出了移植MiniGUI来建立图形界面的方法，并且通过实践验证了该方法的可行性。
HDTV SoC 是用于高清数字电视信号接收端的解码平台。如图1所示：该平台包含以下功能模块：传输流解复用(TSD)，系统控制,音频解码、视频解码，视频处理，显示后处理(OSD)，以及串口等外围设备。视频支持MPEG－II高清和标清解码，音频支持AAC、AC3、MP3、MP2格式。该系统内嵌两颗MIPS CPU分别用作系统控制和音频解码, 设计时钟为108MHz，含有32M SDRAM，8M FLASH。
在HDTV SoC平台上建立图形界面，需要分别利用串口模块（UART）和显示后处理模块（OSD）作为输入和输出设备。充分而高效地将显示后处理模块(OSD)的功能与上层软件有机结合是有效建立图形界面的关键。
MiniGUI是一种针对嵌入式设备的，跨操作系统的轻量级图形界面支持系统。作为操作系统和应用程序之间的中间件，MiniGUI隐藏了底层操作系统与硬件平台的差别，为上层应用程序提供了一致的功能特性。
MiniGUI具有良好的软件架构，通过可移植层（Portable Layer）将MiniGUI上层和底层操作系统隔离开来；可移植层可将特定操作系统及底层硬件的细节隐藏起来，而上层应用程序无需关心底层硬件平台的输入和输出。作为国内广泛应用的嵌入式图形界面中间件产品，相对与其它嵌入式GUI系统，MiniGUI有以下优势：1.轻型，占用资源少。2.高性能，高可靠性。3.可配置。4.可伸缩性强。5.跨操作系统支持
3．移植MiniGUI:
MiniGUI的体系结构可表示如下图：
图2 MiniGUI的体系结构
如图3所示，MiniGUI从上到下包括应用程序，核心层，可移植层（图形与输入设备抽象层）以及输入输出设备层。其中，图形引擎（GAL）和输入引擎（IAL）一起构成可移植层。可移植层为上层提供了统一的输入输出的抽象接口，从而增强了MiniGUI的可移植性。移植MiniGUI主要是根据具体的硬件平台对可移植层及以下各层作相应的修改，大致包括三方面工作。
首先，定制图形引擎。MiniGUI可以支持包括SVGALib 和 LibGGI在内的多种图形引擎，另外还自带了基于framebuffer设备的私有图形引擎。相对于其他图形引擎，私有引擎专为Linux平台上的MiniGUI而设计，有更好的性能和显示效果，因此在Linux平台上被广泛采用。但是该引擎需要Linux内核中包含对显示设备的framebuffer驱动的支持。针对HDTV SoC平台，如果我们采用MiniGUI的私有图形引擎，就需要在Linux内核中添加基于OSD硬件的framebuffer驱动程序。
其次，定制输入引擎。不同的平台在输入引擎上差别较大。HDTV SoC平台采用UART作为输入设备，所以输入引擎要基于UART，将UART得到的外部信息转换为上层应用程序能够理解和识别的信息格式。
最后，需要根据平台特性和应用需求对MiniGUI进行功能配置。
我们将图3中的图形设备（Graphic Device）和输入设备(Input Device)替换为具体的驱动程序及相应的硬件设备可得出MiniGUI在HDTV SoC平台上实现的具体框图如图4所示：
经过以上分析之后，我们更加明确了移植所要做的工作，并且可进一步将整个移植过程分为三阶段：第一，开发和调试基于OSD硬件的framebuffer驱动程序，并且调试图形引擎，这是整个移植过程中最为关键的一步；第二，定制和调试基于UART设备的输入引擎；第三，开发自己的应用程序，并且交叉编译和配置整个MiniGUI。
首先，我们需要开发针对HDTV SoC 平台上OSD硬件设备的framebuffer驱动程序。framebuffer机制定义了一组与显示设备相关的数据结构和操作，对显示设备的帧缓存进行了软件抽象，为上层提供了统一的访问接口，屏蔽了底层硬件的细节。应用程序对该组数据结构和操作进行访问，就可以实现对不同显卡硬件的访问操作。减少依赖于显卡的代码量，同时增加了这部分代码的可移植性。另外，framebuffer机制将显存从内核空间映射到进程空间，实现进程空间对显存的直接访问，提高了显示效率。
如果MiniGUI采用基于framebuffer设备的私有图形引擎，首先需要在内核中添加framebuffer设备驱动。framebuffer设备的实现主要依赖于四个数据结构：
fb_fix_screeninfo用来表示与显示设备无关的常值信息，这些信息在设备初始化时指定，应用程序可以通过借口函数来访问这些信息，但是不允许改变它们。
fb_var_screeninfo用来表示与显示设备无关的变量信息与特定显示模式。应用程序可以调用相应的借口来访问和修改这些信息。
fb_ops是供上层调用的一组函数接口。全部的framebuffer操作最后都要通过该接口来完成。
fb_info 是常规信息，API以及帧缓冲设备的底层信息。该结构只能被用于内核中，前面三个结构均可通过外部接口查看。
在驱动程序中实现了上述四个结构之后，一个简单得framebuffer驱动程序即宣告完成。将该驱动程序作为模块加载之后，就可以进行调试，直到输出正常。
在framebuffer驱动程序完成之后，接下来需要定制输入引擎。MiniGUI通过INPUT数据结构来表示输入引擎。MiniGUI维护着一个由所有输入引擎组成的输入引擎数组，每个数组项对应着一个输入引擎。如果该数组中没有与该平台对应的项，就需要在其中添加对应的输入引擎。由于SoC平台只能通过UART和用户进行交互，所以输入引擎以UART为基础。通过把UART的消息转换为键盘上相应的按键，再送给MiniGUI应用程序。
在图形引擎和输入引擎的定制完成之后，最后需要对MiniGUI的源代码进行交叉编译和安装。到这里，整个移植工作基本结束。在此基础上，我们还可以在MiniGUI平台上开发自己的应用程序。
4．总结：
本文作者创新观点：在SoC平台上建立GUI界面需要充分考虑系统性能，资源以及GUI系统本身的资源消耗，移植开源软件通常是最经济，最简便的办法。移植工作主要是建立GUI系统与输入输出硬件的映射，在必要的时候需要根据GUI系统要求为底层硬件开发专用的驱动程序。由于MiniGUI在SoC芯片上的应用还比较少，所以本次移植工作不仅验证了移植方法的可行性，对于如何为MiniGUI在机顶盒中的应用,以及对于如何在受到资源和性能约束的嵌入式系统中建立图形界面，均具有一定的借鉴意义
评论