基于eCos操作系统的FLASH驱动程序分析与移植

0 引 言
    嵌入式系统需要支持的外部设备种类繁多，如何构造运行良好的嵌入式设备的驱动程序，对嵌入式操作系统的实际应用有重要意义。eCos是一种源代码公开的实时嵌人式操作系统，对嵌入式应用具有良好的支持，内核专门设计了便于设备驱动管理和开发的I／O包和DEV包，开发人员可以方便地将自己开发的驱动程序加入其中，与别的系统组件一起进行配置。

1 系统目标板简介
    硬件目标板是为无人机系统设计的系统开发板，它是从Arca系统测试板经过功能简化设计而来的满足无人机系统要求的目标板。硬件目标板如图1所示。

    GT2000支持SRAM，FLASH，ROM，VLIO(静态段支持可变等待时间I／O设备)和SDRAM(同步动态RAM)等外部扩展存储器。GT2000的外部地址空间是按体(bank)划分的，有四个体属于静态存储器区域，由引脚CS0～CS3选择，在将FLASH，SRAM，VLIO(用作其他外设接口)等静态I／O设备地址分别设计在CS0～CS2区域内，由GT2000内部的外部内存访问接口(EMI)控制器中的静态内存访问控制寄存器(SMCR)进行访问控制，分配地址访问接口。
    系统目标板选用两片Intel公司的TE28F320的FLASH(16位)并联获得32位总线宽度。Intel公司的TE28F320是32 Mb(2 M×16 b)多功能FLASH，2．7～3．6 V单电源供电，读取时间为70 ns，封装格式为48-Pin TSoP(12 mm×20 mm)或48-Ball TFB-GA，可被擦写10 000次。方舟的JTAG仿真器支持TE28F320 FLASH，可以通过JTAG接口进行在线读写和擦除，这给调试程序和硬件提供了方便。
    FLASH的电路原理图以及GT2000的引脚“DACK[2．．1]／MD_MEM[1．．0]”设置如图2所示。

2 eCos驱动程序的体系结构与驱动程序设计模式
    eCos操作系统的设备驱动程序通常包含以下内容：提供一些底层函数，负责完成设备初始化与配置、注册设备，从设备收发数据、控制设备、处理设备中断等，并进行设备管理。eCos操作系统内核支持设备驱动程序的同步、计时、内存管理、缓冲区管理、设备名空间及资源管理等。[!--empirenews.page--]
    eCos系统的I／O包中包含了设备的驱动程序接口模块，全部是以组件的形式存在。设备驱动程序模块支持系统设计的分层结构。设备I／O包中的程序需要使用设备DEV包中的程序，而设备DEV包中的程序需要调用eCos的硬件抽象层包中的底层接口函数，如图3所示。

2．1 设备驱动程序用户API
    eCos为应用程序提供了一组用户API函数，这些操作包括对设备进行初始化和配置，获取配置信息，对设备进行读写等。设备驱动程序必须使用设备句柄进行设备操作，通过cyg_io_lookup()函数把设备在系统中的惟一名字映射成设备句柄。
2．2 eCos驱动程序与内核及HAL的接口
    应用程序在使用设备的时候，通过驱动程序的用户API函数访问设备驱动程序，设备驱动程序又调用设备内核API函数与内核和硬件抽象层HAL进行交互，设备驱动程序和内核又通过硬件抽象层HAL对硬件平台进行操作。
    eCos内核向设备驱动程序提供调度、时钟、同步、中断等内核服务的支持。在某些嵌入式应用中，部分内核服务并不是必需的。在配置时不选择Kernel包，设备驱动程序的内核服务支持由硬件抽象层提供。
    HAL包含所有与平台相关的代码，是eCos操作系统对硬件进行的抽象定义，它直接控制和访问硬件，为eCos内核和高层代码提供服务。
    I／O包和DEV包构成了eCos驱动程序的基本框架。设备驱动程序一般分为三个部分，分别为设备表入口DEVTAB_ENTRY、设备I／O函数表DEVIO_TAB和设备I／O函数。I／O包提供抽象的设备操作支持，应用程序访问设备时使用逻辑设备名，每个设备都对应一个惟一的逻辑设备名。DEV包提供设备操作的底层实现，对硬件通过HAL直接操作。
    eCos中的所有设备驱动程序都使用设备表入口进行描述。设备表入口使用宏DEVTAB_ENTRY()可以生成一个设备表入口数据结构。其中，_handlers指向DEVIO_TABLE入口函数。提供用户应用程序的调用支持；_priv指向设备真正的硬件操作数据结构，提供硬件设备与上层软件的交互。设备I／O入口宏定义如下：

2．3 设备驱动程序的设计模式
    一般来说，eCos提供了三种驱动程序设计模式。设备驱动程序与内核和HAL之间的API接口主要对中断以及中断处理程序的ISR，DSR和线程的同步进行控制和管理。eCos设备驱动程序的中断模块分为三个层次，分别是中断服务程序ISR，中断滞后服务程序DSR和中断线程。中断服务程序ISR在响应中断时立即调用，中断滞后服务程序DSR由ISR发出调用请求后执行，中断线程为驱动程序的客户程序。具体为硬件抽象层HAL对硬件中断源译码，并在最短的时间内调用ISR中断服务程序，ISR对硬件中断可以立即处理，但限于与中断线程交互较少的设备。大多数情况下，需要请求相应的中断滞后服务程序DSR进入线程调度运行，DSR将在ISR执行完成后立即运行。如果需要复杂的中断服务则要用户自己定义中断线程。对于一个具有中断的设备驱动程序，必须提供ISR和DSR。

3 基于方舟开发板的Inter FLASH驱动程序分析与移植
3．1 Inter公司的TE28F320的FLASH芯片驱动程序分柢
    Inter FLASH驱动程序FLASH_28fxxx．inl文件定义了FLASH设备低层的管理设备I／O函数，FLASH_28fxxx_parts．inl文件定义了FLASH设备逻辑信息。eCos系统I／O包使用DEVTAB_ENTRY()和DEVIO_TABLE()定义的_priv指针对FLASH设备低层I／O函数进行调用。具体定义如下：

3．2 系统地址空间的分配方案。
    当MMU内存管理单元的控制寄存器MCR．ATE为0时，地址映射方式变为直接映射物理方式，如图4所示。

    直接映射方式的映射关系是：在使用高速缓存方式时将虚拟地址A1区域(0x80000000~0xA0000000)映射到实际物理地址0x00000000～0x20000000的区域；根据目标开发板的设计规范，系统的FLASH的物理地址从0x00000000开始，系统设计编写程序时使用相应的虚拟地址空间为0x80000000～0x80FFFFFF。SRAM的物理地址从0x04000000开始，使用相应的虚拟地址空间为0x84000000~0x84200000。[!--empirenews.page--]
3．3 修改eCos硬件抽象层中FLASH和SRAM的配置信息以及FLASH设备驱动程序
    不同的两块开发板所采用的芯片，特别是FLASH芯片有可能是不一样的。由于为无人机专门设计开发的目标板使用的是Inter公司的TE28F320的FLASH芯片，与Arca公司使用的FLASH驱动程序不一样，必须修改FLASH驱动及FLASH和SRAM的配置信息。
    (1)SRAM布局文件修改如下：

   
    (3)FLASH驱动程序FLASH_28fxxx．inl文件中的数据定义修改如下：

    (4)修改平台抽象层文件plf_hci．h文件
    由于目标开发板上没有采用EEPROM和HCI(硬件配置接口)的方式存储系统硬件信息，而是采用在eCos平台抽象层中把开发板上的硬件信息静态存储在文件中。在平台抽象层文件plf_hci．h中修改如下：

    4 驱动测试
4．1 Redboot简介
    Redboot是一个标准的嵌入式系统引导和Debug环境，是基于eCos的一个应用程序，使用eCos的硬件抽象层作为它的基础。内含GDBstub，允许从应用程序调试的GDB宿主机链接目标平台，通过串口或网口进行调试。既可以用在产品的开发阶段(调试功能)，也可以用在最终的产品上。
4．2 系统测试结果
    使用eCos图形配置工具对修改好的eCos硬件抽象象层和FLASH设备驱动程序进行裁剪，并用串口进行系统测试，通过minicom显示Redboot运行的FLASH和SRAM地址结果如图5所示。

5 结语

本文通过裁剪和移植FLASH驱动程序到目标开发板上，展示上具体的修改硬件抽象层和设备驱动程序代码方法。通过实际裁剪，配置一个具有实际应用价值的Redboot，对于嵌入式技术的学习和应用具有现实的意义。本文的难点在于eCos硬件抽象层和设备驱动程序源代码的理解和修改。