基于eCos在基于ARM7硬件平台上的应用

摘要:简单介绍eCos的体系结构，详细论述eCos的可配置机制的实现原理，重点介绍eCos在以AT91M55800为核心的ARM7硬件平台上的移植步骤，结合本系统简要介绍内核的配置方法。最后给出了基于eCos应用软件的编写方法。

　　eCos(Embedded Configurable Operating System)最初是由Cygnus Solutions公司为面向嵌入式领域而开发的源码公开、具有很强的可移植性和可配置性的，适合于深度嵌入式开发的实时操作系统。现在eCos主要由eCosCentric公司和eCos开源社区共同开发维护。eCos的特性，特别是它的可配置性，能有效缩短嵌入式产品的开发周期并降低成本。

　　1  eCos的体系结构及可配置性

　　1.1  eCos体系结构

　　eCos采用模块化设计，将不同功能的软件分成不同的组件，使其分别位于系统的不同层次。这种层次结构实现了eCos的可配置性、可移植性、兼容性和可扩展性。图1是eCos系统的层次结构框图。硬件抽象层（HAL）使其上层次结构不必关心具体的硬件结构，因此只需对HAL进行修改就可以使整个eCos的应用移植到新的硬件平台上。

　　图1  eCos的层次结构框图

　　内核是eCos的一个核心组件，也是系统的一个可选组件，一些较为复杂的应用需要内核的支持。内核提供了多个可供选择的调度算法，可以很好地支持多任务处理。eCos内核提供了一组丰富的同步源语，完全能满足各种嵌入式应用的需求。内核还负责对中断和例外进行处理，它的中断滞后处理机制保证了系统的实时性。此外，内核还具有内存分配机制和定时机制，并提供多线程GDB调试支持。内核为上层软件和应用软件提供了丰富的API接口函数。

　　RedBoot是一个无内核的系统引导程序，是eCos的一个特殊应用。RedBoot可以加载eCos应用程序，并提供Debug支持，是开发eCos系统时非常有用的工具。设备驱动程序负责对硬件设备进行控制和管理，并完成设备数据的读/写操作。设备驱动程序自身也采用层次结构，上层驱动程序（相当于一个虚设备）可以调用下层驱动程序（物理设备）。驱动程序为上层软件提供标准的API函数，应用程序可以使用这些API函数对设备进行访问。

　　eCos包含的网络支持包支持完整的TCP/IP网络协议栈。eCos还提供了标准库（ANSI C库和数学库）、兼容层（POSIX兼容和uITRON兼容）、文件系统等。作为一种开放软件，eCos还可以很方便地容纳第三方软件。

　　1.2  可配置性原理

　　eCos的一个主要特性就是其可配置特性。可配置性最终是靠代码中的条件编译来完成的，条件编译是编程语言的特点，并不是eCos的原创。当一个软件工程中的条件编译项的数目和复杂性达到一定程度时，其中有一些条件编译项就会因为存在逻辑上的依赖关系而使条件编译产生冲突。而如何发现并有效解决这种冲突才是eCos可配置性的特点，如图2所示，其可配置特性的实现主要由组件定义语言CDL(Component Definition Language)、组件仓库ecos.db、图形配置工具configtool三者共同完成。

　　图2  可配置机制[!--empirenews.page--]

　　（1）  组件定义语言CDL

　　CDL是eCos组件框架中的一个关键部分，eCos所有模块的程序包中都包含一个CDL脚本对该包进行描述并提供配置选项。以本系统中的串口驱动程序包为例，在该包对应的CDL中定义了一个名为CYGPKG_IO_SERIAL_ARM_AT91的cdl_package。在这个cdl_package中详细列出了该包的一些属性，如该包必须在工程已经包含了硬件抽象层包CYGPKG_HAL_ARM_AT91和上层串口I/O包CYGPKG_IO_SERIAL的情况下才会被使能。另外，串口的一些常用特性，如波特率、设备名、缓冲区大小等配置选项也是必不可少的。在一些复杂的CDL中还会包含对该包中的源程序进行编译时的一些编译选项。在进行配置的时候，该包还会产生一个包含了各个可配置参数数值的头文件。当其他包使用由CYGPKG_IO_SERIAL_ARM_AT91包提供的可配置参数时，这个新产生的头文件就会被相关的源文件通过#include语法包含。

　　（2）  组件仓库ecos.db

　　ecos.db是一个包含了所有可用程序包和配置模版的文本文件。在该文件中，需要注册所有的CDL包。在注册时以package关键字提供相应包的名称、CDL脚本文件的文件路径以及对该包的一个简单描述。在ecos.db中还会以target关键字生成配置模版，从而提供目标平台的一些基本组成结构，使目标平台包括所需要的已经注册了的CDL配置包。

　　（3） 图形配置工具configtool

　　configtool是利用MFC编写的Windows程序，是eCos可配置性的执行者，也可以理解成是CDL脚本的解释器。一方面它读取ecos.db文件中的目标平台和已注册的配置包信息，根据配置包的路径找到相应的CDL脚本，然后根据脚本中给出的属性向程序员提供图形化的配置信息；另一方面，它还可以接受用户的输入，包括单选按钮、复选框、下拉列表、文本输入等。当用户保存一个配置时，configtool会根据CDL语言的提示生成相应的头文件，也会将指定的头文件从配置包中复制到配置文件所在的工作目录。无论是生成的头文件还是拷贝的头文件，都会在编译时被源程序所引用。对于内核源程序，configtool又可以理解成编译器。当用户的配置选项被保存并且对工程进行编译时，configtool会在后台调用真正的编译器GCC，根据配置包CDL中的编译选项控制GCC对所有需要的内核源文件进行编译并生成库文件和对应的链接脚本。当然configtool只是对eCos内核进行编译，用户的应用程序只需在编译时和由configtool编译生成的库文件进行链接就可以得到最终的可执行映像文件。

　　2  系统硬件框架

　　本系统是一个以ARM7为核心构成的测控系统，通过对传感器的脉冲信号进行处理而得到待测物料的流量，并通过控制给料器的给料速度达到流量控制的目的。对于一个有实用价值的测控系统，必须具有人机交互、闭环控制、数据通信和存储等功能。本课题所研制的流量测控系统的硬件框图如图3所示。

　　图3  流量测控系统硬件框图

　　图3中，处理器为ARM7内核的工业级芯片AT91M55800，其强大的功能保证了系统的实时性和稳定性的要求。2 MB的Flash SST39VF160用来保存程序代码、测量所需的一些参数以及测量结果的简单统计信息。在工业生产中,经常需要对一次测量中的数据进行历史再现，以便对一些事故或故障进行排查。本系统通过采用1 MB的大容量RAM来实现这一功能：除了用来作为程序运行时的内存外，RAM还用来实时保存每一时刻的测量数据。USB总线的通信口用来和现场计算机进行通信，以实现一些更加完善的处理，如数据打印、结果分析、实时数据的硬盘保存等。分辨率为320×240的LCD用来作为系统的显示终端配合4×5的键盘来完成系统的人机交互操作。对变频器的控制和对温度信号的采集通过485总线完成。6路脉冲信号是本系统测量功能的核心，通过对这6路脉冲进行处理可以得到流量相关的所有信息。4~20 mA电流信号用来控制给料系统，以实现闭环控制。由于在工业环境中使用，对于一些长线连接必须采取隔离措施。本系统对测量脉冲、485通信信号和4~20 mA电流信号都采取了光电隔离措施。[!--empirenews.page--]

　　3  eCos在系统上的移植与应用软件编写

　　3.1  eCos内核的移植

　　由于eCos内核采用了可配置的模块化设计思想，因此只要修改硬件抽象层HAL的代码和CDL脚本并且在ecos.db中注册就可以应用于新的目标系统。HAL又可以细分为3个层次： ①  体系结构抽象层。eCos是可以应用于多种体系结构平台上的操作系统，如ARM、MIPS、POWERPC等，在eCos发布时已经将这些体系结构层的移植包一同发布了出来。本系统的体系结构抽象层是ARM7体系结构抽象层。②  变体抽象层。对于同一种体系结构的处理器，各生产厂家会有不同的系列和型号（如Atmel的AT91系列、Philips的LPC系列等)，虽然它们都采用ARM7体系结构,但是不同的寄存器配置模式和中断处理方法也会影响到eCos的移植。本系统所使用的处理器AT91M55800使用较为普遍，在eCos开源社区已经有移植好的AT91M55800变体抽象层的代码和CDL脚本，只需作系统启动后对I/O口的赋值情况等少许的改动即可完成对变体抽象层的移植。③  平台抽象层。平台抽象层是对目标系统的整个硬件平台进行抽象，包括平台的启动、芯片配置、定时、I/O寄存器及中断寄存等等。

   移植工作主要是平台抽象层的移植，而平台抽象层中最重要的是Flash驱动包和内存布局文件的移植。主要的步骤为：

　　①  安装AT91M55800变体抽象层包。从eCos开源社区下载好的变体抽象层包在一个名为eb55的文件夹中，在这个文件夹中还有cdl、include、src等子文件夹分别包含了CDL脚本、头文件，源文件。由于eCos的软件包有严格的层次结构，所以在安装软件包时应遵循这一结构以便于维护。AT91M55800属于ARM7的一个变体，同AT91系列的其他CPU处于同一层次，所以变体抽象层软件包文件夹eb55的具体路径应为/hal/arm/at91/eb55。接下来还应在ecos.db中注册变体抽象层包，以package关键字注册名为CYGPKG_HAL_ARM_AT91_EB55的包，这个名字必须和包中CDL文件hal_arm_at91_eb55.cdl中的所定义的包名完全一致。在包名后面的花括号中登记hal_arm_at91_eb55.cdl文件的路径及文件名，以及对该包的简单文字说明。

　　②  编写Flash的底层驱动软件包，以便能够操作目标系统的Flash存储器。由于本系统在前期调试和代码固化时利用了RedBoot，而RedBoot通过Flash驱动程序操作目标Flash，所以必须先移植好Flash驱动程序才能进行更进一步的开发工作。

　　首先需要编写底层驱动程序源文件。不同的Flash的块空间大小以及写操作一般是不一样的。本系统所用的Flash SST39VF160是2 MB的16位NOR Flash，共有512(0x200)个块空间，其块大小为4K(0x1000)，写操作的命令码符合JEDEC标准。这些特点与Atmel公司AT49系列Flash比较类似，因此Flash驱动程序可以从eCos发布时自带的AT49系列Flash的驱动程序修改得到。最重要的地方是修改描述Flash特性的结构体flash_dev_info_t变量中成员block_size和block_count的值，使其分别为0x1000和0x200。

　　接下来需要编写与Flash底层驱动对应CDL脚本，使配置工具configtool能够正确配置编译Flash驱动程序。这个CDL文件完全可以参照AT49驱动包中的CDL文件编写。以cdl_package关键字定义名为CYGPKG_DEVS_Flash_SST_39VF160的包，在命令体中给出具体的配置参数。由于底层驱动包必须结合上层驱动才能工作，所以在命令体中用active_if CYGPKG_IO_Flash命令告诉configtool,必须在上层驱动包CYGPKG_IO_Flash已经被包含的情况下底层驱动包才会使能。

　　最后，需要在ecos.db中注册底层驱动软件包。具体做法和变体抽象层包的注册方法相同。

　　③  修改内存布局文件，使configtool能够正确定位程序在系统存储器中的位置。eCos提供3种不同的运行方式,即ROM方式、RAM方式、ROMRAM方式。每种模式都有两个相应的布局文件，如RAM方式的mlt_arm_at91_eb55_ram.ldi和mlt_arm_at91_eb55_ram.h。*.ldi和常见的ARM开发环境ADS中scattered链接方式下的*.scf文件的作用类似，即用来对不同段分别指定不同的链接地址。在*.ldi中需要修改MEMORY和SECTI*两部分。对于代码在RAM中运行的内核及应用程序，需要根据系统RAM的实际情况修改内存布局文件中相关参数的值。本系统具有1  MB的RAM，但有一半用来存放测量数据，根据系统实际的硬件情况，其起始地址为0x02000000，大小为0x80000，所以这个内存块定义为ram: RIGIN=0x02000000, LENGTH=0x80000。处理器内部集成了8 KB SRAM，其起始地址为0，大小为0x2000，所以这个内存块定义为sram: RIGIN=0x00000000,LENGTH=0x2000。这样系统的MEMORY部分就由名为ram和sram的两个内存块构成。系统比较重要的两处SECTI*部分的修改为SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA) 和SECTION_rom_vectors (ram, 0x02008000, LMA_EQ_VMA)，第一处表示fixed_vectors段分配在从0x20开始的sram中，且LMA_EQ_VMA指定其加载地址等于虚拟地址。由于RedBoot运行时需要占用从0x02000000开始的一定空间的RAM，所以第二处使程序代码从0x02008000开始的ram中运行。*.ldi文件修改完毕后需要相应地修改*.h文件中的宏，如#define CYGMEM_REGION_ram  (0x02000000)。[!--empirenews.page--]

　　④  在组件仓库ecos.db中为以关键字target添加名为Flow55的新目标平台。在这个目标平台中还必须用关键字packages包括ARM7体系结构层包和AT91M55800变体抽象层包，同时为了实现调试还必须包括串口驱动包和Flash驱动包及其上层驱动包。除了这些被包含的软件包外，根据不同的选择configtool还会为目标平台包添加一些默认的包，如内核包、数学库包等。另外，还应加入一些对该平台的简单描述。

　　3.2  内核的配置

　　移植完成以后，一个最基本的目标平台就产生了。在configtool中可以看到Templates菜单的硬件平台列表中新增了Flow55目标平台模版，以default方式打开这个模版。各个软件包的CDL脚本中都给出了默认的配置值，有些值需要根据具体的应用要求重新配置。本系统一些重要的配置情况如下：

　　①  由于系统线程数量较少（小于10），所以选择效率更高的位图调度器Bitmap scheduler，并将线程数numbers of priority levels限定为16，以提高任务切换的速度。当点击位图调度器的单选按钮时，configtool会检测到一个配置冲突。由于时间片轮转是默认使能的，而时间片轮转仅仅对应于多级队列调度器，所以出现配置冲突。Configtool会给出一个推荐的解决冲突的方法,即禁止时间片轮转，按照这个推荐的解决方法可以安全地解决这个冲突。这个地方可以充分体现出eCos强大的可配置性。

　　②  由于配合RedBoot一起使用，所以内核配置为RAM启动方式。这样，系统上电后程序将由RedBoot复制到RAM中运行，以提高速度。

　　③  系统的晶振频率为16 MHz，经PLL倍频后为32 MHz，所以需将Clock speed配置为32000000；RTC是系统的时钟节拍发生器，本系统的时钟节拍时间选为20 ms，所以也需要对RTC相关项进行配置。具体参数为Real?time clock numerator配置为2000000000，Real?time clock denominator配置为100，Real?time clock period配置为20000。

　　其余的配置选项使用默认的配置值即可。完成配置工作后，对内核进行编译可以产生内核库文件和链接脚本以及相关头文件。这些生成的文件再同应用程序一起编译、链接，生成最终的可执行映像文件。

　　图4  应用软件结构

　　3.3  基于eCos操作系统的应用软件的编写

　　eCos是一个单进程多线程的操作系统，多个线程在宏观上可以认为是并发运行的，而且各线程之间耦合低，便于软件的编写和维护。针对这一特点，本系统的软件结构如图4所示。

　　本系统主要有两种程序运行方式，分别称为方式A和方式B。方式A中，硬件中断产生后，相应的ISR(Interrupt Service Routine)程序运行，由于ISR中是禁止中断的，所以在ISR中只进行最简单的操作，ISR退出后内核调用相应的DSR(Deferred Service Routine)。DSR中中断是使能的，所以可以进行一些稍复杂的处理，如简单的数据运算、内核调用（发送信号量和邮箱等）。在得到相应的信号量或消息邮箱后，相应的线程进入就绪态被内核调度运行。本系统中对键盘的处理就是基于这种方式——按键产生硬件中断、ISR执行，接着在DSR中进行相应的运算得到具体的键值后以消息邮箱的方式通知并唤醒键盘处理线程，键盘处理线程在完成任务后进入休眠直到再次有按键发生而被唤醒。方式B中，各线程只是周期性地被内核调度运行，如测量数据显示线程，在显示一次数据后调用延时函数进入休眠，直到延时完毕后再次进入就绪态被内核调用。

　　根据测控系统的实际情况，具体的线程编写如下： 方式A为流量计算线程、温度测量线程、键盘处理线程、USB通信处理线程。方式B为测量数据显示和曲线绘制线程、流量控制线程、初始标定线程。

　　4  结论

　　经过实践，本系统运行稳定，实时性能良好。由于eCos的强大可配置性使得系统的软硬件可维护性强，在进行硬件改动或应用要求改动后可方便地进行升级。