基于嵌入式Linux的图形界面显示系统的设计

　　摘要：本文详细描述了基于uClinux嵌入式操作系统的图形界面显示系统的实现方法，并对uClinux下Framebuffer驱动程序编写进行了专门探讨。

　　关键词：uClinux ，Microwindow，Framebuffer 驱动程序

　　1前言

　　在嵌入式系统这个IT产业的新领域，Linux 以其所具备的稳定、高效、易定制、易裁减、硬件支持广泛的特点，结合其免费、源码开放的特征。使得Linux在嵌入式操作系统中的地位越来越重要。越来越多的嵌入式系统，包括 PDA、机顶盒、WAP 手机等等系统均要求提供全功能的 Web 浏览器。这包括 HTML 的支持、JavaScript 的支持，甚至包括 Java 虚拟机的支持。而这一切都要求有一个高性能、高可靠的 GUI 的支持。这些系统一般不希望建立在庞大累赘的、非常消耗系统资源的操作系统和 GUI 之上，比如 Windows 或 X Window。但是，在出现 Linux 系统之后 GUI 仍然是一个问题。关键是 X Window 太过庞大和臃肿。uClinux是专为无存储器管理单元的处理器定制的嵌入式Linux操作系统。其内嵌的Microwindow为嵌入式系统图形界面提供了良好的支持。

　　2系统的组成结构

　　基于uClinux的嵌入式图形界面显示系统分为软件和硬件两大部分。软件由uClinux、Framebuffer驱动程序和Microwindow三部分组成。Motorola嵌入式CPU 5272、EPSON的13506 LCD 控制器和TRULY公司的MCT-G320240DNCW液晶显示屏组成图形界面显示硬件系统。结构如图1所示。

　　硬件设计环境：开发板是Motorola 5272C3，uClinux内核版本号是2.4.17。

　　3 Microwindow的架构

　　Microwindow是一种轻量级的GUI，具有轻型、占用资源少、高可靠性的特点。Microwindow 是一个非常适合于工业控制实时系统以及嵌入式系统的可定制的、小巧的图形用户界面支持系统。Microwindow是一种分层设计的架构。最底层是一组屏幕、鼠标/触摸屏、键盘的抽象接口，不依赖任何特殊的硬件。中间层是可移植的图形引擎。最高层是各种API，供图形应用程序调用。目前有两种API，一种是ECMA APIW，第二种是NANO-X APIS.。这些API与win32和x window系统基本上兼容，使应用程序移植非常容易。

　　在uClinux下Microwindow最底层的SCREEN 抽象接口建立在linux framebuffer 设备基础上。Framebuffer device 是对图形显示硬件设备的抽象，它代表视频硬件的帧缓存。本文将重点讨论uClinux下针对具体硬件环境如何设计其Framebuffer设备驱动程序。

　　4 Framebuffer设备驱动程序的设计

　　Linux下设备分为字符设备、块设备和网络设备接口三大类。那么Framebuffer设备属于哪一类呢？刚开始设计时容易使人困惑。其实对使用者而言，帧缓冲设备也就是Framebuffer device和目录/dev下的其他设备没有区别。它是一个字符设备，使用主设备号29，次设备号用于帧缓冲设备之间的区分。

　　例如：

　　0＝/dev/fb0 First frame buffer

　　1=/dev/fb1 Second frame buffer

　　…

　　31=/dev/fb31 32nd frame buffer

　　0~31就是次设备号

　　帧缓冲驱动程序主要依靠四个数据结构。这些结构定义在 include/linux/fb.h程序内。它们分别是fb_info、fb_var_screeninfo、fb_fix_screeninfo和fb_monospecs。后三个结构可以在用户空间访问，结构 fb_info只能在内核空间访问。

　　结构 fb_fix_screeninfo定义了视频板卡硬件的某些固定的特性。这些特性在硬件初始化时就被定义了以后不得修改。在这个结构体中最重要的成员是smem_len和line_length。前者指示显存的大小，后者提供了一个显示行的byte统计数，使显存指针很方便的移到下一显示行。

　　结构fb_var_screeninfo定义了视频硬件一些可变的特性。这些特性在程序运行期间可以由应用程序动态改变。由于篇幅有限在此只对这个结构体中主要的成员作出解释，详细解释请参见fb.h。成员变量xres 和 yres定义在显示屏上真实显示的分辨率。而xres_virtual和yres_virtual是虚拟分辨率，它们定义的是显存分辨率。比如显示屏垂直分辨率是400，而虚拟分辨率是800。这就意味着在显存中存储着800行显示行，但是每次只能显示400行。但是显示哪400行呢？这就需要另外一个成员变量yoffset，当yoffset＝0时，从显存0行开始显示400行，如果yoffset＝30，就从显存31行开始显示400行。

　　在这四个结构中最重要的结构就是fb_info，它只能在内核空间访问。其内部定义了struct fb_ops， 结构fb_ops成员就是由一系列Framebuffer 操作函数组成。

　　结构fb_monospecs在2.5.x内核下才会被采用，在目前内核下不使用。

　　如前所述就使用者而言，帧缓冲设备和一般的字符设备没有区别。因此写视频硬件的设备驱动程序就有两种选择，一种是把视频硬件抽象成一般的字符设备，驱动程序的写法和一般的字符设备驱动类似。第二种就是帧缓冲设备的驱动程序的编写。第一种方法不规范，而且实现功能有限，故不提倡。下面用与字符驱动程序类比的方法介绍如何编写帧缓冲驱动程序。

　　字符驱动程序用函数register_chrdev向内核注册设备。register_chrdev需要三个参数，参数一是主设备号，参数二是对应与参数一主设备号的驱动程序名；参数三用来登记驱动程序实际执行操作的函数指针，它指向struct file_operation。编写字符驱动程序的主要工作就是编写各个子函数并填写file_operation各个域。当用户进程利用系统调用对设备文件进行操作时，系统通过设备文件的主设备号找到相应的设备驱动程序。然后读取这个数据结构相应的操作函数指针，接着就把控制权交给这个函数。这就是linux驱动程序工作原理。

　　帧缓冲设备驱动程序与此类似，其调用register_framebuffer注册一个framebuffer设备。它只有一个参数就是前面介绍的struct fb_info， 其内部定义了结构成员fb_ops。编写帧缓冲驱动程序主要就是编写fb_ops各个成员函数。与字符驱动设备不同的是帧缓冲驱动程序并不实现ioctl调用。帧缓冲驱动程序的初始化函数在linux/drivers/video/fbmem.c中登记。所有的帧缓冲驱动程序的ioct调用由fbmem.c统一实现。由fbmem.c根据当前正在工作的帧缓冲设备提供ioctl调用。

　　5 硬件电路的设计

　　5272是Motorola公司Coldfire系列嵌入式CPU，在Motorola公司嵌入式CPU中属于中低档产品。低档不等于低效，在主频66M时可以达到63MIPS，接近MPC860的MIPS。并且外围电路接口丰富，在Coldfire系列中集成度最高。

　　5272总线是一种32位同步数据地址总线，总线传输终止支持同步终止和异步终止。在5272与外围器件总线传输周期中，利用TA信号可以在总线传输周期插入等待时钟周期。实现总线传输的异步终止。5272总线接口使用BS0~BS3四个信号显示当前总线周期数据总线宽度。5272的I/O空间是内存映射的，所以没有专门的I/O地址空间。因为5272没有MMU单元，所以5272的内存空间是物理地址直接寻址。

　　液晶屏控制器是EPSON公司的13506。这是一款LCD/CRT/TV图形控制器。CPU接口广泛。拥有16bit宽度的EDO显存接口，显存最大可达2Mbytes。在16bpp的情况下最大分辨率可达640480。支持虚拟显示，即显示图像尺寸可以大于屏幕实际尺寸。

　　下图是Coldfire 5272 CPU 与 EPSON13506之间的接口电路示意图。

　　EPSON13506的CPU接口数据总线宽度是16位。5272是大印第安字节序，当总线宽度是16位时，数据总线高16位有效。EPSON13506 M/R#管脚用来控制当前读写是对显存的读写还是对13506 I/O寄存器的读写，5272地址线A21对其进行控制。这样在5272 CS6的地址空间中，地址21位是1就是显存的地址，为0就是13506 I/O寄存器的地址。5272地址总线A0并未接到EPSON13506 AB0管脚上，这是由于在EPSON13506 CPU接口模式 Generic1情况下，EPSON13506 AB0管脚必须接高电平。这样就无法实现对字节的寻址。为了实现对字节的寻址，可以通过一片CPLD进行逻辑运算实现对相应管脚的选择，实现字节寻址。

　　整个电路设计的重点难点在于对EPSON13506 CPU接口类型的深入理解，显存和LCD液晶屏的连接比较简单，在这里就不再赘述。

　　6结束语

　　目前越来越多嵌入式系统要求图形显示界面，特别是在一些工业控制领域。本系统已经成功运用于色谱仪工作站上。其友好的人机界面大大降低了仪表操作难度，简化了操作流程，提高了生产效率。

　　参考文献：

　　[1]Allessandro Rubin,Linux Device Drivers O’Reilly&Assocates、Inc、1998

　　[2]陈莉君,Linux操作系统内核分析[M].北京，人民邮电出版社，2000