UCOS和uClinux的比较.doc

UC/OS和uClinux的比较出处：单片机商城 发布日期：2005-9-10 11:14:28 浏览次数：356 UC/OS和uClinux的比较 摘要：嵌入式操作系统是嵌入式系统应用的核心软件。本文通过对两种典型的开源嵌入式操作系统的对比，分析和总结嵌入式操作系统应用中的若干问题，归纳嵌入式操作系统的选型依据。 关键词：嵌入式系统 操作系统 uC/OS uClinux 引言 随着现代计算机技术的飞速发展和互联网技术的广泛应用，从PC时代过渡到了以个人数字助理、手持个人电脑和信息家电为代表的3C（计算机、通信、消费电子）一体的后PC时代。后PC时代里，嵌入式系统扮演了越来越重要的角色，被广泛应用于信息电器、移动设备、网络设备和工控仿真等领域。 嵌入式系统是以嵌入式计算机为核心，面向用户、面向产品、面向应用，软硬件可裁减的，适用于对功能、可靠性、体积、成本、功耗等综合性能有严格要求的计算机系统。随着嵌入式系统的广泛应用，传统的前/后台程序开发机制已经不能满足日益复杂和荷记得的实现要求，因而现场常常采用嵌入式产时操作系统PROS（Real Time Operation System）开发实时多任务系统。嵌入式实时操作系统一般可以提供多任务的任务调度、时间管理、任务间通信和同步以及内存管理MMU（Memory Manager Unit）等重要服务，使得嵌入式应用程序易于设计和扩展。采用RTOS可以使嵌入式产品更可靠、开发周期更短。在嵌入式应用中使用RTOS已经成为当前嵌入式应用的一个热点。 完成简单功能的嵌入式系统一般不需要操作系统。如，以前许多MCS51系列单片机组成的小系统就只是利用软件实现简单的控制环路；但是随着所谓后PC时代的来临，嵌入式系统设计日趋复杂，嵌入式操作系统就必不可少了。 嵌入式RTOS在系统实时高效性、硬件的相关依赖性、软件固化以及应用的专业性等方面具有较为突出的优势。一般而言，嵌入式操作系统不同于一般意义的计算机操作系统，它有占用空间小、执行效率高、方便进行个性化定制和软件要求固化存储等特点。 从20世纪80年代起，国际上就有一些IT组织、公司，开始进行商用嵌入式操作系统和专用操作系统的研发。这其中涌现了一些著名的嵌入式操作系统，如Microsoft公司的WinCE和WindRiver System公司的VxWorks就分别是非实时和实时嵌入式操作系统的代表。但是商用产品的造价都十分昂贵，用于一般用途会提高产品成本从而失去竞争力。 UC/OS和uClinux操作系统是用两种性能优良、源码公开且被广泛应用的免费嵌入式操作系统，可以作为研究实时操作系统和非实时操作系统的典范。本文通过uC/OS和uClinux的对比，分析和总结嵌入式操作系统应用中的若干重要问题，归纳嵌入式系统开发中操作系统的选型依据。 1 两种开源嵌入式操作系统介绍 uC/OS和uClinux操作系统，是当前得到广泛应用的两种免费且公开源码的嵌入式操作系统。UC/OS适合小型控制系统，具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点，最小内核可编译至2KB。UClinux则是继承标准Linux的优良特性，针对嵌入式处理器的特点设计的一种操作系统，具有内嵌网络协议、支持多种文件系统，开发者可利用标准Linux先验知识等优势。其编译后目标文件可控制在几百KB量级。 UC/OS是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。其内核提供任务调度与管理、时间管理、任务间同步与通信、内存管理和中断服务等功能。 UClinux是一种优秀的嵌入式Linux版本。uClinux是Micro-Conrol-Linux的缩写。同标准Linux相比，它集成了标准Linux操作系统的稳定性、强大网络功能和出色的文件系统等主要优点。但是由于没有MMU（内存管理单元），其多任务的实现需要一定技巧。 2 两种嵌入式操作系统主要性能比较 嵌入式操作系统是嵌入式系统软硬件资源的控制中心，它以尽量合理的有效方法组织多个用户共享嵌入式系统的各种资源。其中用户指的是系统程序之上的所有软件。所谓合理有效的方法，指的就是操作系统如何协调并充分利用硬件资源来实现多任务。复杂的操作系统都支持文件系统，方便组织文件并易于对其规范化操作。 嵌入式操作系统还有一个特点是，针对不同的平台，系统不是直接可用的，一般需要经过针对专门平台的移植操作系统才能正常工作。 进程调度、文件系统支持和系统移植是在嵌入式操作系统实际应用中最常见的问题。下文就从这几个角度入手对uC/OS和uClinux进行分析比较。 2.1 进程调度 任务调度主要是协调任务对计算机系统资源（如内存、I/O设备、CPU）的争夺使用。进程调度又称为CPU调度，其根本任务是按照某种原理为处于就绪状态的进程分析CPU。由于嵌入式系统中内存和I/O设备一般都和CPU同时归属于某进程，所以任务调度和进程调度概念相近，很多场合不加区分。 进程调度可分为“剥夺型调度”和“非剥夺型调度”两种基本方式。所谓“非剥夺型调度”是指：一旦某个进程被调度执行，则该进程一直执行下去直至该进程结束，或由于某种原理自行放弃CPU进入等待状态，才将CPU重新分配给其它进程。所谓“剥夺型调度”是指：一旦就绪状态中出现优先权更高的进程，或者运行的进程已用满了规定的时间片时，便立即剥夺当前进程的运行（将其放回就绪状态），把CPU分配给其它进程。 作为实时操作系统，uC/OS采用的是可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。uC/OS中最多可以支持64个任务，分别对应优先级063，其中0为最高优先级。调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。 其最高优先级任务表来实现的。UC/OS中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB（Task Control Block）的数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量OSTCBHighRdy记录当前最高级就绪任务的TCB地址，然后调用OS_TASK_SW（）函数来进行任务切换。 UClinux的进程调度沿用了Linux的传统。系统每隔一定时间挂起进程，同时产生快速和周期性的时钟性时中断，并通过调度函数（定时器处理函数）决定进程什么时候拥有它的时间片，然后进行相关进程切换。这是通过父进程调用fork函数生成子进程来实现的。 UClinux系统fork调用完成后，要么子进程代替父进程执行（此时父进程已经休眠），直到子进程调用exit退出；要么调用exec执行一个新的进程，这时产生可执行文件的加载，即使这个进程只是父进程的拷贝，这个过程也不可避免。当子进程执行exit或exec后，子进程使用wakeup把父进程唤醒，使父进程继续往下执行。 uClinux由于没有MMU管理存储器，其对内存的访问是直接的，所有程序中访问的地址都是实际的物理地址。操作系统对内存空间没有保护，各个进程实际上共享一个运行空间。这就需要实现多进程时进行数据保护，也导致了用户程序使用的空间可能占用到系统内核空间。这些问题在编程时都需要多加注意，否则容易导致系统崩溃。 由上述分析可以得知，uC/OS内核是针对实时系统的要求设计实现的，相对简单，可以满足较高的实时性要求；而uClinux则在结构上继承了标准Linux的多任务实现方式，仅针对嵌入式处理器特点进行改良。其要实现实时性效果则需要使系统在实时内核的控制下运行。RT-Linux就是可以实现这一功能的一种实时内核。 2.2 文件系统 所谓文件系统是反映负责存取和管理文件信息的机构，也可以说是负责文件的建立、撤销、组织、读写、修改、复制及对文件管理所需要的资源（如目录表、存储介质等）实施管理的软件部分。 uC/OS是面向中小型嵌入式系统的。如果包含全部功能（信号量、消息邮箱、消息队列及相关函数），编译后的uC/OS内核仅有610KB，所以系统本身并没有对文件系统的支持。但是uC/OS具有良好的扩展性能，如果需要的话也可自行加入文件系统的内容。 uClinux则是继承了Linux完善的文件系统性能。其采用的是romfs文件系统。这种文件系统相对于一般的ext2文件系统要求更少的空间。空间的节约来自于两个方面：首先，内核支持romfs文件系统比支持ext2文件系统需要更少的代码；其次，romfs文件系统相对简单，在建立文件系统超级块（superblock）需要更少的存储空间。Romfs文件系统不支持动态擦写保存，对于系统需要动态保存的数据采用虚拟ram盘的方法进行处理（ram盘将采用ext2文件系统）。 uClinux还继承了Linux网络操作系统的优势，可以很方便地支持网络文件系统且内嵌TCP/IP协议。这为uClinux开发网络接入设备提供了便利。 由两种操作系统对文件系统的支持可知：在复杂的需要较多文件处理的嵌入式系统中，uClinux是一个不错的选择；而uC/OS则主要适合一些控制系统。 2.3 操作系统的移植 嵌入式操作系统移植的目的是指使操作系统能在某个微处理器或微控制器上运行。UC/OS和uClinux都是源码公开的操作系统，且其结构化设计便于把与处理器相关的部分分离出来，所以被移植到新的处理器上是可能的。以下对两种系统的移植分别予以说明。 （1）uC/OS的移植 要移植uC/OS，目标处理器必须满足以下要求： *处理器的C编译器能产生可重入代码，且用C语言就可以打开和关闭中断； *处理器支持中断，并能产生定时中断； *处理器支持足够的RAM（几KB），作为多任务环境下的任务堆栈； *处理器有将堆栈指针和其它CPU寄存器读出和存储到堆栈或内存中的指令。 在理解了处理器和C编译器的技术细节后，uC/OS的移植只需要修改与处理器相关的代码就可以了。具体有如下内容： *OS_CPU.H中需要设置一个常量来标识堆栈增长方向； *OS_CPU.H中需要声明几个用于开关中断和任务切换的宏； *OS_CPU.H中需要针对具体处理器的字长重新定义一系列数据类型； *OS_CPU_A.ASM需要改写4个汇编语言的函数； *OS_CPU_C.C需要用C语言编写6个简单函数； *修改主头文件INCLUDE.H，将上面的三个文件和其它的头文件加入。 （2）uClinux的移植 其实，uClinux是Linux针对嵌入式系统的一种改良，其结构比较复杂；相对uC/OS,uClinux的移植也复杂得多。一般而言，要移植uClinux，目标处理器除了应满足上述uC/OS应满足的条件外，还需要具有足够容量（几百KB以上）外部ROM和RAM。 uClinux的移植大致可以分为3个层次。 *结构层次的移植。如果待移植处理器的结构不同于任何已经支持的处理器结构，则需要修改linux/arch目录下相关处理器结构的文件。虽然uClinux内核代码的大部分是独立于处理器和其体系结构的，但是其最低级的代码也是特定于各个系统的。这主要表现在它们的中断处理上下文、内核映射的维护、任务上下文和初始化过程都是独特的。这些例行程序位于lunux/arch/目录下。由于Linux所支持体系结构的种类繁多，所以对一个新型的体系，其低级例程可以模仿与其相似的体系例程编写。 *平台层次的移植。如果待移植处理器是某种uClinux已支持体系的处理器，则需要在相关体系结构目录下建立相应目录并编写相应代码。如MC68EZ328就是基于无MMU的m68k内核的。此时的移植需要创建的linux/arch/m68knommu/platform/MC68EZ328目录下，并在其下编写跟踪程序（实现用户程序到内核函数的接口等功能）、中断控制调度程序和向量初始化程序等。 *极级移植。如果所用处理器已被uClinux支持，就只需要板级移植了。板级移植需要在linux/arch/?platform/中建立一个相应板的目录，再在其中建立相应的启动代码crt0_rom.s或crt0_ram.s和键接描述文档rom.ld或ram.ld就可以了。板级移植还包括驱动程序的编写和环境变量设置等内容。 结语 通过对uC/OS和uClinux的比较可以看出，这两种操作系统在应用方面各有优劣。uC/OS占用空间少、执行效率高、实时性能优良，且针对新处理器的移植相对简单。UClinux则占用空间相对较大，实时性能一般，针对新处理器的移植相对复杂。但是，uClinux具有对多种文件系统的支持能力、内嵌了TCP/IP协议，可以借鉴Linux丰富的资源，对一些复杂的应用，uClinux具有相当优势。例如，CISCO公司的2500/3000/4000路由器就是基于uClinux操作系统开发的。总之，操作系统的选择是由嵌入式系统的需求决定的。简单地说就是，小型控制系统可充分利用uC/OS小巧且实时性强的优势；如果开发PDA和互联网连接终端等较和为复杂的系统，则uClinux是不错的选择。16:41| 添加评论| 固定链接| 引用通告 (0)| 写入日志嵌入式系统 Boot Loader 技术内幕嵌入式系统 Boot Loader 技术内幕（一）出处：单片机商城 发布日期：2005-7-4 16:50:53 浏览次数：364 引言在专用的嵌入式板子运行Linux 系统已经变得越来越流行。一个嵌入式 Linux 系统从软件的角度看通常可以分为四个层次：1. 引导加载程序。包括固化在固件(firmware)中的 boot 代码(可选)，和 Boot Loader 两大部分。 2. Linux 内核。特定于嵌入式板子的定制内核以及内核的启动参数。 3. 文件系统。包括根文件系统和建立于 Flash 内存设备之上文件系统。通常用 ram disk 来作为 root fs。 4. 用户应用程序。特定于用户的应用程序。有时在用户应用程序和内核层之间可能还会包括一个嵌入式图形用户界面。常用的嵌入式 GUI 有：MicroWindows 和 MiniGUI 等。引导加载程序是系统加电后运行的第一段软件代码。回忆一下 PC 的体系结构我们可以知道，PC 机中的引导加载程序由 BIOS(其本质就是一段固件程序)和位于硬盘 MBR 中的 OS Boot Loader（比如，LILO 和 GRUB 等）一起组成。BIOS 在完成硬件检测和资源分配后，将硬盘 MBR 中的 Boot Loader 读到系统的 RAM 中，然后将控制权交给 OS Boot Loader。Boot Loader 的主要运行任务就是将内核映象从硬盘上读到 RAM 中，然后跳转到内核的入口点去运行，也即开始启动操作系统。而在嵌入式系统中，通常并没有像 BIOS 那样的固件程序（注，有的嵌入式 CPU 也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由 Boot Loader 来完成。比如在一个基于 ARM7TDMI core 的嵌入式系统中，系统在上电或复位时通常都从地址 0x00000000 处开始执行，而在这个地址处安排的通常就是系统的 Boot Loader 程序。本文将从 Boot Loader 的概念、Boot Loader 的主要任务、Boot Loader 的框架结构以及 Boot Loader 的安装等四个方面来讨论嵌入式系统的 Boot Loader。（一）Boot Loader 的概念 简单地说，Boot Loader 就是在操作系统内核运行之前运行的一段小程序。通过这段小程序，我们可以初始化硬件设备、建立内存空间的映射图，从而将系统的软硬件环境带到一个合适的状态，以便为最终调用操作系统内核准备好正确的环境。通常，Boot Loader 是严重地依赖于硬件而实现的，特别是在嵌入式世界。因此，在嵌入式世界里建立一个通用的 Boot Loader 几乎是不可能的。尽管如此，我们仍然可以对Boot Loader 归纳出一些通用的概念来，以指导用户特定的 Boot Loader 设计与实现。1. Boot Loader 所支持的 CPU 和嵌入式板2. 每种不同的 CPU 体系结构都有不同的 Boot Loader。有些 Boot Loader 也支持多种体系结构的 CPU，比如 U-Boot 就同时支持 ARM 体系结构和MIPS 体系结构。除了依赖于CPU 的体系结构外，Boot Loader 实际上也依赖于具体的嵌入式板级设备的配置。这也就是说，对于两块不同的嵌入式板而言，即使它们是基于同一种 CPU 而构建的，要想让运行在一块板子上的 Boot Loader 程序也能运行在另一块板子上，通常也都需要修改 Boot Loader 的源程序。 3. Boot Loader 的安装媒介（Installation Medium）系统加电或复位后，所有的 CPU 通常都从某个由 CPU 制造商预先安排的地址上取指令。比如，基于 ARM7TDMI core 的 CPU 在复位时通常都从地址 0x00000000 取它的第一条指令。而基于 CPU 构建的嵌入式系统通常都有某种类型的固态存储设备(比如：ROM、EEPROM 或 FLASH 等)被映射到这个预先安排的地址上。因此在系统加电后，CPU 将首先执行 Boot Loader 程序。4. 用来控制 Boot Loader 的设备或机制 主机和目标机之间一般通过串口建立连接，Boot Loader 软件在执行时通常会通过串口来进行 I/O，比如：输出打印信息到串口，从串口读取用户控制字符等。 5. Boot Loader 的启动过程是单阶段（Single Stage）还是多阶段（Multi-Stage）通常多阶段的 Boot Loader 能提供更为复杂的功能，以及更好的可移植性。从固态存储设备上启动的 Boot Loader 大多都是 2 阶段的启动过程，也即启动过程可以分为 stage 1 和 stage 2 两部分。而至于在 stage 1 和 stage 2 具体完成哪些任务将在下面讨论。6. Boot Loader 的操作模式 (Operation Mode)大多数 Boot Loader 都包含两种不同的操作模式：启动加载模式和下载模式，这种区别仅对于开发人员才有意义。但从最终用户的角度看，Boot Loader 的作用就是用来加载操作系统，而并不存在所谓的启动加载模式与下载工作模式的区别。启动加载（Boot loading）模式：这种模式也称为自主（Autonomous）模式。也即Boot Loader 从目标机上的某个固态存储设备上将操作系统加载到 RAM 中运行，整个过程并没有用户的介入。这种模式是 Boot Loader 的正常工作模式，因此在嵌入式产品发布的时侯，Boot Loader 显然必须工作在这种模式下。下载（Downloading）模式：在这种模式下，目标机上的 Boot Loader 将通过串口连接或网络连接等通信手段从主机（Host）下载文件，比如：下载内核映像和根文件系统映像等。从主机下载的文件通常首先被 Boot Loader 保存到目标机的 RAM 中，然后再被Boot Loader 写到目标机上的FLASH 类固态存储设备中。Boot Loader 的这种模式通常在第一次安装内核与根文件系统时被使用；此外，以后的系统更新也会使用 Boot Loader 的这种工作模式。工作于这种模式下的 Boot Loader 通常都会向它的终端用户提供一个简单的命令行接口。像 Blob 或 U-Boot 等这样功能强大的 Boot Loader 通常同时支持这两种工作模式，而且允许用户在这两种工作模式之间进行切换。比如，Blob 在启动时处于正常的启动加载模式，但是它会延时 10 秒等待终端用户按下任意键而将 blob 切换到下载模式。如果在 10 秒内没有用户按键，则 blob 继续启动 Linux 内核。7. BootLoader 与主机之间进行文件传输所用的通信设备及协议最常见的情况就是，目标机上的 Boot Loader 通过串口与主机之间进行文件传输，传输 协议通常是 xmodemymodemzmodem 协议中的一种。但是，串口传输的速度是有限的，因此通过以太网连接并借助 TFTP 协议来下载文件是个更好的选择。此外，在论及这个话题时，主机方所用的软件也要考虑。比如，在通过以太网连接和 TFTP 协议来下载文件时，主机方必须有一个软件用来的提供 TFTP 服务。在讨论了 BootLoader 的上述概念后，下面我们来具体看看 BootLoader 的应该完成哪些任务16:35| 添加评论| 固定链接| 引用通告 (0)| 写入日志嵌入式系统中LCD驱动的实现原理嵌入式系统中LCD驱动的实现原理出处：单片机商城 发布日期：2006-6-9 17:23:17 浏览次数：111 结合三星公司ARM9系列嵌入式处理器S3C2410，讲解如何进行LCD驱动程序模块化编程及如何将驱动程序静态加载进系统内核。 LCD（液晶显示）模块满足了嵌入式系统日益提高的要求，它可以显示汉字、字符和图形，同时还具有低压、低功耗、体积小、重量轻和超薄等很多优点。随着嵌入式系统的应用越来越广泛，功能也越来越强大，对系统中的人机界面的要求也越来越高，在应用需求的驱使下，许多工作在Linux下的图形界面软件包的开发和移植工作中都涉及到底层LCD驱动的开发问题。因此在嵌入式系统中开发LCD驱动得以广泛运用。 本文以三星公司ARM9内核芯片S3C2410的LCD接口为基础，介绍了在Linux平台上开发嵌入式LCD驱动程序的一般方法。 本文硬件采用三星公司的S3C2410芯片的开发板，软件采用Linux 2.4.19平台，编译器为arm-linux-gcc的交叉编译器，使用640480分辨率的TFT彩色LCD，通过对其Linux驱动程序进行改写和调试，成功地实现了对该种屏的驱动和显示。 嵌入式驱动的概念 设备驱动程序是操作系统内核和机器硬件之间的接口，设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以像操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它主要完成的功能有：对设备进行初始化和释放；把数据从内核传送到硬件和从硬件读取数据；读取应用程序传送给设备文件的数据、回送应用程序请求的数据以及检测和处理设备出现的错误。 Linux将设备分为最基本的两大类：一类是字符设备，另一类是块设备。字符设备和块设备的主要区别是：在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了。字符设备以单个字节为单位进行顺序读写操作，通常不使用缓冲技术；块设备则是以固定大小的数据块进行存储和读写的，如硬盘、软盘等，并利用一块系统内存作为缓冲区。为提高效率，系统对于块设备的读写提供了缓存机制，由于涉及缓冲区管理、调度和同步等问题，实现起来比字符设备复杂得多。LCD是以字符设备方式加以访问和管理的，Linux把显示驱动看做字符设备，把要显示的数据一字节一字节地送往LCD驱动器。 Linux的设备管理是和文件系统紧密结合的，各种设备都以文件的形式存放在/dev目录下，称为设备文件。应用程序可以打开、关闭和读写这些设备文件，完成对设备的操作，就像操作普通的数据文件一样。为了管理这些设备，系统为设备编了号，每个设备号又分为主设备号和次设备号。主设备号用来区分不同种类的设备，而次设备号用来区分同一类型的多个设备。对于常用设备，Linux有约定俗成的编号，如硬盘的主设备号是3。Linux为所有的设备文件都提供了统一的操作函数接口，方法是使用数据结构struct file_operations。这个数据结构中包括许多操作函数的指针，如open()、close()、read()和write()等，但由于外设的种类较多，操作方式各不相同。Struct file_operations结构体中的成员为一系列的接口函数，如用于读/写的read/write函数和用于控制的ioctl等。打开一个文件就是调用这个文件file_operations中的open操作。不同类型的文件有不同的file_operations成员函数，如普通的磁盘数据文件，接口函数完成磁盘数据块读写操作；而对于各种设备文件，则最终调用各自驱动程序中的I/O函数进行具体设备的操作。这样，应用程序根本不必考虑操作的是设备还是普通文件，可一律当作文件处理，具有非常清晰统一的I/O接口。所以file_operations是文件层次的I/O接口。 LCD控制器 LCD控制器的功能是显示驱动信号，进而驱动LCD。用户只需要通过读写一系列的寄存器，完成配置和显示驱动。在驱动LCD设计的过程中首要的是配置LCD控制器，而在配置LCD控制器中最重要的一步则是帧缓冲区（FrameBuffer）的指定。用户所要显示的内容皆是从缓冲区中读出，从而显示到屏幕上的。帧缓冲区的大小由屏幕的分辨率和显示色彩数决定。驱动帧缓冲的实现是整个驱动开发过程的重点。S3C2410中的LCD控制器可支持STN和TFT两种液晶。对于STN 液晶平板，该LCD控制器可支持4位双扫描、4位单扫描和8位单扫描三种显示类型，支持4级和16级灰度级单色显示模式，支持256色和4096色显示，可接多种分辨率的LCD，例如640480、320240和160160等，在256色显示模式时，最大可支持40961024、20482048和10244096显示。TFT液晶平板可支持1-2-4-8bpp（bits per pixel）调色板显示模式和16bpp非调色板真彩显示。 帧缓冲区是出现在Linux 2.2.xx及以后版本内核当中的一种驱动程序接口，这种接口将显示设备抽象为帧缓冲区设备区。帧缓冲区为图像硬件设备提供了一种抽象化处理，它代表了一些视频硬件设备,允许应用软件通过定义明确的界面来访问图像硬件设备。这样软件无须了解任何涉及硬件底层驱动的东西（如硬件寄存器）。它允许上层应用程序在图形模式下直接对显示缓冲区进行读写和I/O控制等操作。通过专门的设备节点可对该设备进行访问，如/dev/fb*。用户可以将它看成是显示内存的一个映像，将其映射到进程地址空间之后，就可以进行读写操作，而读写操作可以反映到LCD。 帧缓冲设备对应的设备文件是/dev/fb*。如果系统有多个显卡，Linux还支持多个帧缓冲设备，最多可达32个，即/dev/fb0/dev/fb31。而/dev/fb则指向当前的帧缓冲设备，通常情况下，默认的帧缓冲设备为/dev/fb0。 帧缓冲设备也属于字符设备，采用“文件层-驱动层”的接口方式。在文件层为之定义了以下数据结构。 Static struct file_operations fb_fops= ower: THIS_MODULE, read: fb_read, /*读操作*/ write: fb_write, /*写操作*/ ioct1: fb_ioct1, /*I/O操作*/ mmap: fb_mmap, /*映射操作*/ open: fb_open, /*打开操作*/ release: fb_release, /*关闭操作*/ 其成员函数都在linux/driver/video/fbmem.c中定义，其中的函数对具体的硬件进行操作，对寄存器进行设置，对显示缓冲进行映射。主要结构体还有以下几个。 Struct fb_fix_screeninfo：记录了帧缓冲设备和指定显示模式的不可修改信息。它包含了屏幕缓冲区的物理地址和长度。 Struct fb_var_screeninfo：记录了帧缓冲设备和指定显示模式的可修改信息。它包括显示屏幕的分辨率、每个像素的比特数和一些时序变量。其中变量xres定义了屏幕一行所占的像素数，yres定义了屏幕一列所占的像素数，bits_per_pixel定义了每个像素用多少个位来表示。 Struct fb_info：Linux为帧缓冲设备定义的驱动层接口。它不仅包含了底层函数，而且还有记录设备状态的数据。每个帧缓冲设备都与一个fb_info结构相对应。其中成员变量modename为设备名称，fontname为显示字体，fbops为指向底层操作的函数的指针。 LCD驱动开发的主要工作 1 编写初始化函数 初始化函数首先初始化LCD控制器，通过写寄存器设置显示模式和颜色数，然后分配LCD显示缓冲区。在Linux中可以用kmalloc()函数分配一段连续的空间。缓冲区大小为：点阵行数点阵列数用于表示一个像素的比特数/8。缓冲区通常分配在大容量的片外SDRAM中，起始地址保存在LCD控制寄存器中。本文采用的LCD显示方式为640480，16位彩色，则需要分配的显示缓冲区为6404802=600kb。最后是初始化一个fb_info结构，填充其中的成员变量，并调用register_framebuffer(&fb_info)，将fb_info登记入内核。 2 编写成员函数 编写结构fb_info中函数指针fb_ops对应的成员函数，对于嵌入式系统的简单实现，只需要下列三个函数就可以了。 struct fb_ops int (*fb_get_fix)(struct fb_fix_screeninfo *fix, int con, struct fb_info *info); int (*fb_get_var)(struct fb_var_screeninfo *var, int con, struct fb_info *info); int (*fb_set_var)(struct fb_var_screeninfo *var, int con, struct fb_info *info); Struct fb_ops在include/linux/fb.h中定义。这些函数都是用来设置/获取fb_info结构中的成员变量的。当应用程序对设备文件进行ioctl操作时候会调用它们。对于fb_get_fix()，应用程序传入的是fb_fix_screeninfo结构，在函数中对其成员变量赋值，主要是smem_start（缓冲区起始地址）和smem_len（缓冲区长度），最终返回给应用程序。而fb_set_var()函数的传入参数是fb_var_screeninfo，函数中需要对xres、yres和bits_per_pixel赋值。 对于/dev/fb，对显示设备的操作主要有以下几种。 读/写（read/write）/dev/fb：相当于读/写屏幕缓冲区。 映射（map）操作：由于Linux工作在保护模式，每个应用程序都有自己的虚拟地址空间，在应用程序中是不能直接访问物理缓冲区地址的。为此，Linux在文件操作 file_operations结构中提供了mmap函数，可将文件的内容映射到用户空间。对于帧缓冲设备，则可通过映射操作，可将屏幕缓冲区的物理地址映射到用户空间的一段虚拟地址中，之后用户就可以通过读写这段虚拟地址访问屏幕缓冲区，在屏幕上绘图了。 I/O控制：对于帧缓冲设备，对设备文件的ioctl操作可读取/设置显示设备及屏幕的参数，如分辨率、显示颜色数和屏幕大小等。ioctl的操作是由底层的驱动程序来完成的。在应用程序中，操作/dev/fb的一般步骤如下：打开/dev/fb设备文件；用ioctrl操作取得当前显示屏幕的参数，如屏幕分辨率和每个像素的比特数，根据屏幕参数可计算屏幕缓冲区的大小；将屏幕缓冲区映射到用户空间；映射后即可直接读写屏幕缓冲区，进行绘图和图片显示了。 LCD模块化驱动 在对S3C2410的LCD编写模块化驱动程序时，首先要从内核中去除LCD驱动。这里需要做一些改动，系统调用被加在以下文件中，需去除：/root/usr/src/arm/linux/kernel/sys.c；/root/usr/src/arm/linux/include/arm-arm下的unistd.h和lcd.h；/root/usr/src/arm/linux/arch/arm/kernel下的calls.s。 编写模块化驱动程序，有以下几个关键的函数。 lcd_kernel_init(void)/当模块被载入时执行 lcd_kernel_exit(void)/当模块被移出内核空间时被执行 lcd_kernel1_ioctl(struct*inode, struct*file, unsigned int cmd, unsigned longarg) /其他功能 每当装配设备驱动程序时，系统自动调用初始化模块lcd_kernel_init(void)。 另一个必须提供的函数是lcd_kernel_exit(void)，它在模块被卸载时调用，负责进行设备驱动程序的工作。 执行insmod lcd.o命令即可将LCD驱动添加到内核中，执行rmmod lcd命令即可从内核中删除LCD驱动。 静态加载LCD驱动 将写好的lcd驱动程序lcd.c放到arm/linux/drivers/char目录下，修改arm/linux/drivers/char/config.in文件，加上一行：BoolLCD driver supportCONFIG_LCD；修改arm/linux/drivers/char/Makefile文件，加上一行：obj-$(CONFIG_LCD)+=lcd.o。 这样，当再进行make xconfig时，就会选择是否将LCD驱动编译进内核。同样的办法也可用在其他设备上。16:13| 添加评论| 固定链接| 引用通告 (0)| 写入日志一步一步教你在skyeye上运行uboot出处：单片机商城 发布日期：2006-6-9 17:29:57 浏览次数：87 1. 简介 skyeye是一个很好的，基于各种ARM系列CPU的，SOC和主板级的模拟器。uboot是一个可以在各种cpu（arm，mips，powerpc）的主板上运行的引导程序，相当于PC机的BIOS但是又远远的强于普通的BIOS，比如支持网络引导，引导各种内核，甚至一个简单的shell，等等。他们两个都是基于GPL的开源自由软件。 这篇文章教你怎样在最少量的修改代码的情况下，用skyeye模拟EP7312并在上面运行uboot，给接触嵌入系统的新手一个感性的认识。 2. 建立开发环境 2.1 skyeye模拟器的安装 开发环境是建立在Linux上的。首先下载安装skyeyes-的源代码包，解压，按照里面的readme安装，注意你的linux要有gtk的支持。安装的时候要以root的身份。在各种linux发行版下的安装注意事项参照论坛的相关帖子。安装成功以后，把skyeye的目标目录加入你的路径，这样你就可以在任何目录下执行skyeye模拟器了。 2.2 交叉编译器的安装 交叉编译器是运行在主机上编译另外一种体系结构的编译器。比如，我的主机是linux在x86上，我现在要编译基于ARM的代码，所以我就不能用普通的编译器而需要交叉编译器。我曾经试过自己从gcc的源代码构建交叉编译器，很麻烦和耗时。uboot的作者同样也开发了一个很好的交叉编译器叫ELDK（Embedded linux development kit）。我就使用这个，当然你也可以使用其他嵌入式公司提供的。你可以从以下的网址查看提供ELDK的镜像: ELDK Availability: http:/www.denx.de/twiki/bin/view/DULG/ELDKAvailability ELDK有三个版本分别编译MIPS，PPC和ARM。我从下面的镜像下载了基于ARM的交叉编译器： /ftp/pub/linux/eldk/3.1/arm-linux-x86/iso/ 文件为arm-2004-11-09.iso，它支持ARM7, ARM9, XScale, AT91RM9200 and other ARM based systems。 安装交叉编译器，我将交叉编译器安装到自己的目录“/opt/x86-arm/”里面：code/mnt/cdrom/install -d /opt/x86-arm/code 等待安装结束以后设置好用户环境：codeexport PATH=$PATH:/opt/x86-arm/usr/bin:/opt/x86-arm/binexport CROSS_COMPILE=arm-linux-/code这样你在任何目录也可以访问交叉编译器了。 测试：codearm-linux-gcc -o testarm test.cfile testarmtestarm: ELF 32-bit LSB executable, ARM, version 1 (ARM), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped./code 说明你编译好的文件是ARM上的代码了。你可以用arm-linux-gcc来编译你的文件了。 3. 修改Uboot 从uboot的网站上可以下载到最新的uboot源代码，你可以从以下的网址下载 /ftp:/ftp.denx.de/pub/u-boot/ uboot的源码结构清晰，注释详细，是学习嵌入系统的很好的例子。我下载的是最新的U-Boot-1.1.2。因为我们要模拟EP7312的芯片，而uboot已经支持一个基于EP7312的板子了，所以我们只要对uboot里面有关EP7312的板子的配置略作修改就可以了。uboot里面有关主板的配置文件都在include/configs/.h下，所以我们找到include/configs/ep7312.h，对它进行修改。code找到#define CONFIG_DRIVER_CS8900 1改为#define CONFIG_DRIVER_CS8900 0 找到#define CONFIG_COMMANDS (CONFIG_CMD_DFL | CFG_CMD_JFFS2)改为#define CONFIG_COMMANDS (CONFIG_CMD_DFL) /*Skyeye doesnt have jffs2*/code 然后回到uboot的根目录下，配置，编译：codemake ep7312_configmake all/code等待结束以后我们会发现u-boot.bin和u-boot两个文件，其中u-boot.bin是raw的二进制文件。u-boot是ELF格式的。 4. 配置skyeye，并运行uboot 首先，新建一个目录代表你的EP7312的主板。这样也可以保持文件的清洁和有序。codemkdir board01/code将你刚才编译成功的u-boot.bin拷贝到这个目录下来。skyeye支持raw binary和ELF的格式，这里我们用raw binary的格式。 编辑skyeye.conf，这个文件是用来配置主板的，详细说明见skyeye的相关文档。我的skyeye.conf如下：code#skyeye config file for ubootcpu: arm720tmach: ep7312 mem_bank: map=I, type=RW, addr=0x80000000, size=0x00010000 #skyeye for uboot flash 16M bank 1mem_bank: map=M, type=RW, addr=0x00000000, size=0x01000000, file=./u-boot.bin,boot=yes #skyeye for uboot sdram 16m bank 1mem_bank: map=M, type=RW, addr=0xc0000000, size=0x01000000/code注意这里的内存的地址和容量的分配都是根据uboot里面的ep7312的配置文件调整的。这样也可以是我们对uboot的代码修改做到最小。 这时候你的skyeye-ep7312主板就配置好了。你可以试着运行了。在你现在的目录下打入：codeskyeye/code 然后在skyeye的界面下打入：codetarget simrun/code这时候你可以看到uboot的启动界面，和提示符，如果你键入“hlep”，可以查看所有uboot支持的命令，键入“version”可以查看当前uboot的版本，等等。 5. 进一步的工作 由于本文是最基本的介绍性的一步一步的指导。有很多工作还要去尝试。比如： 由于现在skyeye还不支持flash内存，所以我们是不是可以修改uboot上ep7312相对flash的代码来临时满足我们的需要，不然的话，对于在uboot上面的环境参数的设置，我们只能去修改源码里面的缺省参数。 Uboot支持8019AS的以太网控制器，skyeye也支持了这个硬件的模拟，我们要进一步的使uboot的网络也在sky