分类： LINUX
2012-05-06 21:44:53
在前面的介绍中，我们已经建好了ecos的开发环境。下面我们来分析这个开发环境，以便我们能熟练利用它来开发软件：
一、文件布局
1.ecosenv.csh和ecosenv.sh里的内容是一样的，内容如下：
显然，这里就是将三个路径加入环境变量ECOS_REPOSITORY和PATH中，前者指定了ecos组件库的路径，而后者包含了ecos图形配置工具configtool的路径和交叉编译工具的路径。
Ecos安装工具建立这个文件，就是为了方便我们在做其它工作之前，调用一下：
Source ecosenv.sh
将当前这三个关键路径加入环境变量中。
2.gnutools文件夹
这个文件夹我们感兴趣的就是它包含了我们需要的所有交叉编译工具：
3.ecos-3.0文件夹
这是我们要关注的重点，我们先来看一下这个文件夹顶层的布局：
Package文件夹：包含了ecos组件库。
Tools文件夹：包含了ecos的图形配置工具configtool。其中有工具的可执行文件和源码文件，以及其它的辅助文件。
Example文件夹：包含一些应用例子
Acsupport文件夹：里面包含了开发环境会用到的一些脚本文件
Doc文件夹：包含一些帮助文件。
4.子文件夹package下的布局：
Compat文件夹：包含了兼容POSIX (IEEE 1003.1) 和ìITRON 3.0的API。
Cygmon文件夹：包含支持Cygmon的包。
Devs:设备驱动
Error:包含通用的错误和状态码
Fs:包含支持的文件系统
Hal：硬件抽象层相关代码，我们做移植工作的关键步骤。
Infra:ecos相关的基础代码
Io:硬件无关的输入输出部分
Isoinfra:ISO C库文件和POSIX的实现
Kernel:ecos实时内核源代码
Language:包含ISO 和数学库
Net:网络相关实现
Pkgconf：
Redboot:包含redboot的实现代码
Services:包括对动态内存分配和压缩解压缩的支持包
Templates:
Ecos.db:包含ecos配置工具所需要的可配置数据。
二．ecos开发环境对源码的可配置机制
在理解ecos开发环境可配置机制之前，我们先来认识一下ecos系统里两个最重要的概念：组件管理工具和组件。
组件管理工具集在英文中叫component framework，里面包含了一个命令行配置工具、一个图形化配置工具、存储空间布局工具和包管理工具。
组件，在英文里叫components，它是一个功能相对独立的软件模块的封装，比如kernel组件,HAL组件等。
Ecos采用组件管理工具集(component framework)对组件（component）、组件包(package)和配置选项(option)等可配置资源进行管理，通过收集开发人员所做配置的配置信息来更新.ecc配置文件，从而实现对组件源码的可配置机制。
要记住这里的层次关系：package--àcomponent--àoption;
组件包(package)是组件（component）的发布单位，封装了与组件相关的源码文件，头文件，配置文件，帮助文件以及与组件相关的其它文件。
包管理工具可以对组件库中的包进行添加，更新和删除等操作。
当我们要添加新包的时候，需要通过手动编辑ecos.db数据库文件来完成新包的注册。只有这样，配置工具才会知道新增包的存在，才会知道怎么去管理这个包的配置。
Ecos.db数据库文件里只包含两种结构，即package和target,举例如下：
package CYGPKG_HAL_ARM
{
alias { "ARM common HAL" hal_arm arm_hal arm_arch_hal }
directory hal/arm/arch
script hal_arm.cdl
hardware
description "
The ARM architecture HAL package provides generic support for this
processor architecture. It is also necessary to select a specific
target platform HAL package."
}
package CYGPKG_HAL_ARM_MX27
{
alias { "Freescale i.MX27 Chipset" hal_arm_mx27 }
directory hal/arm/mx27/var
script hal_arm_mx27.cdl
hardware
description "
The MX27 HAL package provides the support needed to run
eCos on Freescale i.MX27 based systems."
}
package CYGPKG_HAL_ARM_MX27_MX27ADS
{
alias { "Freescale i.MX27 ADS board" hal_arm_mx27ads }
directory hal/arm/mx27/mx27ads
script hal_arm_mx27_mx27ads.cdl
hardware
description "
The ADS HAL package provides the support needed to run
eCos on a Freescale i.MX27 ADS board."
}
target mx27ads
{
alias { "Freescale i.MX27 ADS board" mx27 mx27ads }
packages
{
CYGPKG_HAL_ARM
CYGPKG_HAL_ARM_MX27
CYGPKG_HAL_ARM_MX27_MX27ADS
}
description "
The mx27ads target provides the packages needed to run
eCos on a Freescale i.MX27 ADS board."
}
由上面可以看出,其实target就是多个package的封装组合。每个package中的directory 指定了这个包cdl文件所在的目录，而script则指定了这个包所对应的Cdl文件名,通过cdl文件可以知道源码文件列表。
下面我们看cdl文件的结构：
cdl_package CYGPKG_HAL_ARM_MX27_MX27ADS
{
display "Freescale mx27ads board"
parent CYGPKG_HAL_ARM_MX27
define_header hal_arm_mx27_mx27ads.h
include_dir cyg/hal
hardware
implements CYGINT_HAL_DEBUG_GDB_STUBS
implements CYGINT_HAL_DEBUG_GDB_STUBS_BREAK
implements CYGINT_HAL_VIRTUAL_VECTOR_SUPPORT
implements CYGHWR_HAL_ARM_DUART_UARTA
implements CYGHWR_HAL_ARM_SOC_UART1
implements CYGHWR_DEVS_FLASH_MXC_NAND_RESET_WORKAROUND
description "
This HAL platform package provides generic
support for the Freescale mx27ads Board."
compile board_misc.c board_diag.c
define_proc
{
puts $::cdl_system_header "#define CYGBLD_HAL_TARGET_H
" puts $::cdl_system_header "#define CYGBLD_HAL_VARIANT_H
" puts $::cdl_system_header "#define CYGBLD_HAL_PLATFORM_H
" puts $::cdl_header "#define HAL_PLATFORM_CPU \"Freescale i.mx27 based\""
puts $::cdl_header "#define HAL_PLATFORM_BOARD \"MX27 ADS\""
puts $::cdl_header "#define HAL_PLATFORM_MACHINE_TYPE 846"
puts $::cdl_header "#define HAL_ARCH_PROGRAM_NEW_STACK board_program_new_stack"
}
。。。。。。。。
cdl_component CYG_HAL_STARTUP
{
display "Startup type"
flavor data
default_value {"ROM"}
legal_values {"RAM" "ROM" "ROMRAM"}
no_define
define -file system.h CYG_HAL_STARTUP
description "
When targetting the eval board it is possible to build
the system for either RAM bootstrap or ROM bootstrap(s). Select
'ram' when building programs to load into RAM using eCos GDB
stubs. Select 'rom' when building a stand-alone application
which will be put into ROM, or for the special case of
building the eCos GDB stubs themselves. Using ROMRAM will allow
the program to exist in ROM, but be copied to RAM during startup."
}
。。。。。。。。。。
cdl_interface CYGHWR_HAL_ARM_DUART_UARTA
{
display "ST16552 UARTA available as diagnostic/debug channel"
description " The board has a ST16552 DUART chip. This
interface allows a platform to indicate that the specified
serial port can be used as a diagnostic and/or debug channel."
}
。。。。。。。。。
cdl_option CYGNUM_HAL_VIRTUAL_VECTOR_DEBUG_CHANNEL_BAUD
{
display "GDB serial port baud rate"
flavor data
legal_values 9600 19200 38400 57600 115200
default_value 115200
description "
This option selects the baud rate used for the GDB port.
Note: this should match the value chosen for the console port if the
console and GDB port are the same."
}
。。。。。。。。。。
}
重点关注：compile board_misc.c board_diag.c，这一行列出了本包要编译的源码文件列表。
由上面cdl文件的内容可以看出，cdl文件中包含的对象有：
Package,Component,interface,option.
Package描述了该配置包的显示内容、父配置包、需要包含的头文件、源文件列表，还有其它的Component,interface,option等。
Component组件是ecos可配置系统中的功能单元，用它来配置某一特定功能，通过安装或移除组件可以用来禁止或使能这一组件所对应功能。
option是ecos可配置系统中的基本配置单元，一个option对应一个选择项，这个选择项可以是禁止、使能或者是设定为某个值。每个option都有一个宏与之对应，这个宏用于源代码的配置。
到此，我们已经初步了解ecos开发环境对源码的可配置机制的结构层次：最上层是配置工具本身，接下来是eecos.db数据库文件，再接下来是就是cdl脚本文件，最后就是源码文件。
基本的配置过程我想大家猜也能猜出个大概了：配置工具通过分析ecos.db文件中的package定义，可以建立起顶层的配置项；接着借助package定义中directory和script字段的索引找到对于cdl文件，通过分析cdl文件就可以建立起其它所有的配置项；在建立起来可配置树之后，配置工具会分析用户对相应的配置项所做配置，记录当前设置到.ecc配置文件中。
通过以上分析可以看出，与linux的文件控制机制相比，ecos的文件控制机制其实显得更加简洁。
三，编译过程的熟悉
1.先看配置工具的工作目录的布局如下：
2.进入终端，执行如下命令：
cd /home/zengdebiao/ecos/
source ecosenv.sh
ecosconfig new sa1100mm
如下：
3.执行完上面命令后，我们查看工作目录下的变化：
比开始多了一个文件ecos.ecc,这就是我们前面提到的配置保存文件，当前这个文件里的配置只是默认配置，我们用ultraEdit打开看下内容：
4.继续执行如下命令：
ecosconfig import /home/zengdebiao/ecos/ecos-3.0/packages/hal/arm/sa11x0/sa1100mm/v3_0/misc/redboot_ROM.ecm
UltraEdit马上报告ecos.ecc被修改，做了哪些修改，上面提示很清楚，上面命令就是从指定的配置文件导入配置，覆盖前面的默认配置ecos.ecc，
5,这个时候，我们没有发现有新文件生成，继续如下命令：
ecosconfig tree
命令完成后查看工作目录如下：
糟糕，文件夹下多了很多文件夹，刚才忘了建立一个单独的文件夹来探讨这个过程，现在只能硬着头皮往下做了：
我来理一下：除了起初的四个文件加上面生成的ecos.ecc共5个文件或文件夹外，其它都是这次生成树生成的文件夹和文件。
这次生成的文件又可分两类：install文件夹属于安装树，其它属创建树。创建树由顶层的makefile文件和各子目录下的makefile组成，
目前创建树下的每个子文件夹下除了包含makefile文件外，没有包含任何文件。而安装树下/install文件夹中只有两个文件夹，
/lib目前是空，而include/pkgconf文件夹下包括如下头文件：
我们一定要清楚现在文件和文件夹的情况，否则，下面的步骤不知道配置工具做了哪些工作。
6.运行make命令:
呵呵，make过程停止，有错误发生。但先别急着找错在哪，先看从make开始到现在，都做了什么。不看不知道，一看吓一跳，
工具在这个过程中为下面的过程准备好了所有头文件：
与之前相比，/include文件夹下多了4个子文件夹和很多头文件，而且每个新增的子文件下保存的也都是相关部分的头文件：
到此，我们知道了很多信息了。在生成树的过程中，创建了/include/pkgconf下那部分头文件，make过程的前期，创建其它所有相关的头文件，
自然接下来就是根据创建树中的makefile树，一个一个编译源代码，最终链接生成目标文件。
7.由提示信息，是交叉编译工具不对，打开ecos文件下的makefile:
将其中export COMMAND_PREFIX := arm-elf-做如下改动即可：
8.继续执行如下操作：
先清除刚才产生的文件，在重新make.
make clean
make
问题依旧，由此可知，刚改一个makefile肯定不行，必须想其它办法解决所有makefile中这一项的修正。
从ecos.ecc入手，打开文件，找COMMAND_PREFIX的配置选项，将其中的user_value的值做如下改动：
保存，重新生成树：
ecosconfig tree
make
编译成功，
8查看这一步系统生成了些什么文件
和一些中间文件：
看安装树下：
/include文件夹中文件没变，看/lib文件夹：
这就是我们最终生成的目标文件。
好了，通过以上几个方面的介绍，我想我们对ecos的开发环境已经有了比较深入的了解，如果还有需要补充的部分，
大家可以提出来，我抽时间补上。
