结合用户程序的自启动vxWorks制作 兼比较*.a和*.o库(zz)

摘要： 本文通过对嵌入式操作系统vxWorks实用性的介绍，提出了结合用户程序的自启动vxWorks制作的重要性，然后分别介绍了基于源文件.c、编译后文件.o以及档案库文件.a的静态和动态链接方式的自启动vxWorks制作方法，最后分析比较了它们的优劣。
关键词： vxWorks 动态链接 档案库

 

Linking Method of Auto-booting vxWorks Integrated with User’s Applications
Abstract: This paper presents the practicability of embedded real-time operating system vxWorks, from which raises the importance of auto-booting vxWorks integrated with user’s applications. Then it introduces three linking method: static linking with .c source files, static linking with .o output files and the last: dynamic linking with .a archive files. At last, advantages and disadvantages of each method is analyzed and compared.
Keywords: vxWorks Dynamic linking Archives

1． 引言
随着高位嵌入式处理器的日益普及，近年来嵌入式操作系统得到了迅猛的发展，并越来越多地被应用于通讯、国防、工业控制、医疗设备等方面。由于嵌入式系统直接面对硬件，一般的设计模式是将嵌入式操作系统以及用户程序制作成不需要任何操作人员干预的自启动（auto-boot）软件，对系统的控制采取pc或工作站通过网口下传命令的方式。结合用户程序的嵌入式操作系统的制作和优化由此变得重要。vxWorks是嵌入式操作系统领域中应用得最广的一种，通常使用直接使用源文件*.c的静态链接方法来制作结合用户程序的自启动vxWorks，而本文将提出一种新的基于档案库（archives）的制作方法，具有文档管理方便、自动优化最终软件、非常易于移植等优点。
2． vxWorks简介
vxWorks是由Wind River公司开发的一种强实时性嵌入操作系统，支持Mortorola PowerPC, ARM等多种嵌入式CPU。Wind River同时提供集成开发环境Tornado。用户程序编制使用标准C，也可以选择C++支持。Tornado还提供动态下载、远程源级调试器、目标和工具管理、系统目标跟踪、内存使用分析和自动配置，非常适合于交互式开发。
通常所指的vxWorks操作系统对应软件包括三个部分：引导程序bootrom、主操作系统vxWorks、以及用户开发程序。
自启动指不需要操作人员干预，程序在系统上电时自动执行。从上表中可以看出，vxWorks操作系统在开发中三个部分被分开修改编译，只要bootrom制作完毕，就可以在不改动硬件的条件下改变vxWorks操作系统和用户开发程序的下载途径，灵活方便，易于开发。而开发完毕后，所有的硬件都固化到单板硬件，不再需要任何干预，简单快捷。
BSP指板级支持包（Board Support Package），安装完毕后就是Torando目录下\\\\TARGET\\\\CONFIG\\\\下的一个文件夹，例如ads860，就是一个支持PowerPC860的BSP。这个目录中包括了编译bootrom和vxWorks需要的与CPU类型直接相关的程序，对单板上的其他硬件，通过用户添加文件提供驱动。对系统的裁减可以通过修改源码和config.h中的宏定义#define INCLUDE_XXX直接进行，而对编译参数的设定则通过修改makefile进行。将目录\\\\target\\\\config\\\\目录下的all文件夹拷贝到BSP目录下，在makefile下添加CONFIG_ALL= all，然后修改bootConfig.c中的autoboot()函数改变默认的启动方式：网络下载还是从Flash直接启动。

3． 操作系统软件制作
1) 软件制作方法简介
Tornado提供一个集成的编译bootrom、vxWorks以及用户程序的工程环境，此外bootrom和vxWorks的编译还可以使用命令行的方式，也就是通过在dos环境下（win98下运行command，win2000下运行cmd）直接输入命令的方式进行。由于bootrom的工程环境下编译实际上就是采用了命令行方式，且使用命令行方式制作bootrom和vxWorks可以结合批处理的方法，更加方便快捷，因此本文中介绍的bootrom和vxWorks制作方法选用命令行方式。而用户程序的制作可以单独建立工程独立编译，但编译选项中必须选择和相应vxWorks相同的CPU类型。
Bootrom和vxWorks的制作可以通过建立一个批处理文件makeAll.bat完成。文件内容如下：
首先设置环境变量，这些环境变量的设置和tornado安装目录下host\\\\x86-win32\\\\bin中torvars.bat的内容一致。
set WIND_HOST_TYPE=x86-win32
set WIND_BASE=C:\\\\Tornado
set PATH=%WIND_BASE%\\\\host\\\\%WIND_HOST_TYPE%\\\\bin;%PATH%
然后编译bootrom，这里选择可用于烧入rom的bootrom.hex
make bootrom.hex
再编译vxWorks，并选择带符号表的vxWorks.st，最后制作成调入内存就可以直接使用的二进制文件vxWork.bin。
make vxWorks.st
elfToBin <vxWorks.st> vxWorks.bin
直接运行makeAll.bat，如果没有任何语法错误，将生成bootrom.hex，vxWorks.st和vxWorks.bin。vxWorks.st是用于网络下载的操作系统文件，vxWorks.bin用于烧入Flash。

2) 基于静态链接的自启动vxWorks制作
用户程序在开发过程中使用单独的工程编译，编译结束生成一批和.c文件同名的.o文件，这些文件通过target server动态下载，这样提供便捷的调试环境，但需要主机环境的支持。当开发结束后，需要给操作人员提供最方便的启动方式，因此必须将用户程序也编译链接到vxWorks.bin中，在vxWorks启动后就直接启动用户程序。链接方式包括静态链接和动态链接两种。静态链接将提供的所有函数都链接到vxWorks中，而动态链接只链接被调用的函数，用户开发过程中用于测试而在最终系统中并不运行的函数将不被链接。通过使用nm可以察看包括vxWorks.st在内的hex类型文件中含有的函数声明和全局变量，在命令行下输入：nmppc --numeric-sort vxWorks.st >symTab.txt，将vxWork.st中含有的函数和全局变量写到文件symTab.txt中，可以分别察看静、动态链接产生的vxWorks对用户程序中的函数包含情况。这里使用命令arppc同样是因为CPU属于PowerPC。

静态链接有两种方式：.c的链接和.o的链接。

.c的链接方式：先在BSP目录下建立用户程序文件夹usrAPI，将所有用户源程序拷贝到此目录下，然后在usrConfig.c的usrRoot()函数结尾处调用用户程序，需要在usrConfig.c程序开始添加声明：#include “用户程序名.c”

.o的链接方式：同样建立目录usrAPI，将在工程中编译生成的.o文件拷贝到usrAPI，在makefile中添加LIB_EXTRA的定义来将.o包括到vxWorks中，例如用户程序生成了a.o和b.o，则makefile中加入：LIB_EXTRA = usrAPI/a.o usrAPI/b.o，同样修改usrRoot（）函数，并在usrConfig.c程序开始添加外部函数声明：extern 函数类型 函数名（参数……）

或者直接制作一个usrAPI.h，在这个文件中用上面的形式声明所有出现在这些.o中的函数，然后再需要使用到这些函数的文件头部都加上#include “usrAPI/usrAPI.h”。这种方法更有利于程序的规划整齐，并且有助于日后察看函数的使用形式。
最后运行已经制作好的makeAll.bat，生成的vxWorks已经包含自启动的用户程序了。

3) 基于动态链接的自启动vxWorks制作
动态链接使用.a文件。同样制作usrAPI目录并拷贝.o文件，然后在此目录下建立批处理文件makeA.bat。内容如下：
首先是设定环境变量：
set WIND_HOST_TYPE=x86-win32
set WIND_BASE=C:\\\\Tornado
set PATH=%WIND_BASE%\\\\host\\\\%WIND_HOST_TYPE%\\\\bin;%PATH%
然后使用ar工具将所有.o加入到一个档案库文件usrAPI.a中。需要说明的是：arppc是因为我采用的bsp是powerpc类型的，别的cpu类型也类似。
arppc -crusv usrAPI.a a.o b.o
接下来类似于静态链接的.o方式，建立usrAPI.h并在需要的文件中引用。
最后在makefile中加入LIB_EXTRA = usrAPI/usrAPI.a，运行makeAll.bat生成vxWorks。

4． 不同链接方法的对比
基于.c的链接方法将所有用户编写的源程序保留在BSP文件夹中，移植时不利于程序的版权保密。而在不同BSP之间用户程序的移植更是不方便，虽然这种方法不需要对makefile进行任何改动，修改的只是.c文件，比较容易理解，但仍然不推荐使用。
基于.o的链接方法保留了全部的的测试函数接口，并且移植时提供编译过的.o文件也比提供源代码.c文件利于保密。用户源程序和BSP源程序分开，文档结构整齐，特别是对源程序比较庞杂的时候，使用库文件.o或者.a更加有利于文件管理。

基于.a的链接方法只保留必要的函数接口，自动优化了vxWorks的文件大小，因此将对单板的flash大小要求降到最低。这种方法同时使用户程序在不同BSP间的移植变得非常简单。对于一个新的BSP，所需要的就是把usrAPI目录和makeA.bat整个拷贝过去，用基于这个BSP类型的编译方法制作.o文件覆盖usrAPI目录下的.o，拷贝原BSP中makefile中LIB_EXTRA = usrAPI/usrAPI.a到新BSP目录下的makefile中，使用原BSP中usrConfig.c和bootConfig.c中的autoboot()函数和usrRoot()函数结尾覆盖新BSP中相应的部分，最后运行makeA.bat和makeAll.bat，就将用户程序完全移植了。全部移植工作只是一些文件和代码的复制以及批处理文件的运行，十分方便。如果需要将新的.o加入档案库文件，也只需要拷贝此文件到usrAPI目录，在makeA.bat中的arppc -crusv usrAPI.a a.o b.o 后面加上这个新的.o，然后在运行一次makeA.bat就可以了。
唯一需要注意的是，如果在生成了bootrom和vxWorks之后，希望通过更新.o来更新vxWorks中包含的用户程序，不仅需要重新运行makeA.bat重新usrAPI.a，还需要在命令行下输入make clean，将vxWorks和bsp目录下（不含子目录，因此用户程序生成的.o程序不受影响）所有的*.o、*.rpo、vxWorks*、bootrom*、stdt.c、symTbl.c和depend.[bspName]删除，然后运行makeA.bat。因为编译时会自动检查bootrom和vxWorks的存在以及原BSP目录下文件有没有改变，如果没有改变，则认为没有重新编译的必要。这样运行makeA.bat不会更新bootrom和vxWorks，而使用make clean之后，系统检测不到bootrom和vxWorks的存在，就会重新编译了。如果觉得在命令行下输入太麻烦，希望每次都强制更新，只需要在makeAll.bat程序最开始加上一行make clean就可以了。

5． 总结
本文介绍了vxWorks操作系统的软件制作方法，分别总结基于.c的静态链接、基于.o的静态链接和基于.a的动态链接编译方法，并比较了各自的优劣。着重推荐了基于档案库.a的动态链接编译方法，应用该方法使文档管理方便、最终软件大小被优化到最小、并且十分有利于用户程序在不同BSP间的移植，十分适用于制作结合用户程序的自启动vxWorks。

参考文献：
[1] Tornado 2.0 Online Manuals – Tornado User’s Guide (Windows Version),2.0,Edition 1
[2] Tornado 2.0 Online Manuals – GNU Toolkit User’s Guide 2.7.2 Edition1: The GNU Binary Utilities, 2.7.2, May.1993
[3] 孔祥营、柏桂枝，嵌入式实时操作系统vxWorks及其开发环境Tornado[M]，中国电力出版社，2002