EEPW论坛

usrConfig.c在TORNADO下是不执行的.

"说只有在命令行方式make才行",据说是用DOS的方式下的命令进行编译!我也没用过!

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

在命令模式下使用make bootrom;make vxworks时跟bootconfig.c和usrconfig.c挂接