一种可移植的嵌入式图形支持系统：MiniGUI
加入技术交流群
基于MiniGUI的嵌入式系统软件结构
为什么MiniGUI能够在如此众多的嵌入式操作系统上运行？这是因为MiniGUI具有良好的软件架构，通过抽象层将MiniGUI上层和底层操作系统隔离开来。如图2所示，基于MiniGUI的应用程序一般通过 ANSI C库以及MiniGUI自身提供的API来实现自己的功能；MiniGUI中的“可移植层”可将特定操作系统及底层硬件的细节隐藏起来，而上层应用程序则无需关心底层的硬件平台输出和输入设备。
另外，MiniGUI特有的运行模式概念，也为跨操作系统的支持提供了便利。
与Linux这样的类UNIX操作系统相比，一般意义上的传统嵌入式操作系统具有一些特殊性。举例而言，诸如uClinux、uC/OS-II、eCos、VxWorks等操作系统，通常运行在没有内存管理单元的CPU上；这时，往往就没有进程的概念，而只有线程或者任务的概念，这样，GUI系统的运行环境也就大相径庭。因此，为了适合不同的操作系统环境，我们可将MiniGUI配置成三种运行模式：
1．MiniGUI-Threads。运行在MiniGUI-Threads上的程序可以在不同的线程中建立多个窗口，但所有的窗口在一个进程或者地址空间中运行。这种运行模式非常适合于大多数传统意义上的嵌入式操作系统，如uC/OS-II、eCos、VxWorks、pSOS等等。当然，在Linux和uClinux上，MiniGUI也能以MiniGUI-Threads的模式运行。
2． MiniGUI-Lite。与MiniGUI-Threads相反，MiniGUI-Lite上的每个程序是单独的进程，每个进程也可以建立多个窗口。MiniGUI-Lite适合于具有完整UNIX特性的嵌入式操作系统，比如嵌入式Linux。
3． MiniGUI-Standalone。这种运行模式下，MiniGUI能以独立进程的方式运行，既不需要多线程也不需要多进程的支持，这种运行模式适合功能单一的应用场合。例如在一些使用uClinux的嵌入式产品中，因为各种原因而缺少线程支持，这时，就可以使用MiniGUI-Standalone来开发应用软件。
一般而言，MiniGUI-Standalone模式的适应面最广，可以支持几乎所有的操作系统，甚至包括类似DOS这样的操作系统；MiniGUI-Threads模式的适用面次之，可运行在支持多任务的实时嵌入式操作系统，或者具备完整UNIX特性的普通操作系统；MiniGUI-Lite模式的适用面较小，它仅适合于具备完整UNIX特性的普通操作系统。
不论采用哪种运行模式，MiniGUI为上层应用软件提供了最大程度上的一致性；只有少数几个涉及初始化的接口在不同运行模式上有所不同。
MiniGUI在uC/OS-II操作系统上的移植
下面以uC/OS-II操作系统为例，简单介绍MiniGUI到该操作系统上的移植。
uC/OS-II非常简单，只要有一个普通的C编译器，就能完成编译并运行该操作系统，因此，uC/OS-II首先在教学中得到了广泛应用。因为其简单及实时性好的特点，现在也有一些用户开始使用uC/OS-II操作系统开发正式的嵌入式产品。
将MiniGUI移植到uC/OS-II是相对复杂的一项工作。因为uC/OS-II中缺乏象malloc/free甚至是printf/fprintf/sprintf这样的接口，不过，最重要的还是缺乏与POSIX-Threads兼容的接口。为此，我们编写了POSIX-Threads的绕转接口，这些绕转接口兼容于POSIX-Threads。同时，我们还实现了 malloc/free，以及printf/sprintf/fprintf等接口。
因涉及到如此多底层特性的增强和修改，整个系统的调试将是非常困难的。为解决调试问题，我们首先在SkyEye(清华大学陈渝主持的自由软件项目)模拟器上运行uC/OS-II操作系统及MiniGUI for uC/OS-II。我们首先使用了MiniGUI内部的Dummy GAL引擎和Dummy/Auto IAL 引擎(这两个引擎分别通过软件方法来模拟实际的输出和输入设备，如LCD显示屏及键盘)来运行MiniGUI的应用程序。尽管我们看不到真实的屏幕输出，但从应用程序在运行过程中打印的输出信息，我们可以看到MiniGUI for uC/OS-II已经正常工作了。接下来的工作就是将MiniGUI for uC/OS-II移植到正式的硬件产品中。
我们在S3C2410开发板上用ADS的armcc编译并测试了MiniGUI的uC/OS-II版本。这次，我们针对这个开发板编写了正式的图形和输入引擎。MiniGUI的所有示例程序都可以在这块开发板上正常运行。
评论