1.今天上午搞定了trackball，先去找Don讨论了一下USB的进展，然后打算尝试一下trackball，他把好的拆了，所以就拿了一个线已经被剪掉的用。测试了一下是好的，可是接到我的班子上的时候竟然没有识别出来，我又在主机上试了一下，发现是接触不良。由于敢着去开会，所以暂时先放下了。开会的时候说到进展，我还是如实说还没成功，但是怀疑是接触的问题，于是老板让我去买个新的：）不过会后我check了一下线路，就成功搞定了。
2.老板开会的时候又开我玩笑，说我什么都没做：）我于是说"I am going to do some work",结果大家都大笑了：）不过十二点会议的时候老板把我给报上了，也就是说未来三个月，得为一篇journal paper奋斗一下了。不过我也正有此意，这篇就写anti-rollover control。我还计划暑期写一篇track control的paper，然后再写一篇系统方面的会议，投IEEE EMBS。估计这几篇文章都比较偏engineering一些。等到focus group完了后，可以写一篇偏临床的，然后就看毕业前能招多少subjects来决定另外的文章了。当然，有机会关于manual wheelchair propulsion和sports data logger方面的文章也是可以考虑的。
3.转入正题，整理一下vxWorks的应用程序自启动，明天开始调试这个：
3.1 基于静态链接的自启动VxWorks
用户程序在开发过程中使用单独的工程编译，编译结束后生成一批和.c文件同名的.o文件，这些文件通过target server动态下载，这样提供便捷的调试环境 ，但需要主机环境的支持。当开发结束后，需要给操作人员提供最方便的启动方式，因此必须将用户程序也编译链接到VxWorks.bin中，在VxWorks启动后就直接启动用户程序。链接方式包括静态链接和动态链接两种。静态链接将提供的所有函数都链接到VxWorks中，而动态链接只链接被调用的函数。
静态链接有两种方式 ：.c的链接和.o的链接。
.c的链接方式：先在BSP目录下建立用户程序文件夹usrAPI，将所有用户源程序拷贝到此目录下，然后在usrconfig.c的usrroot()函数结尾处调用用户程序 ，需要在usrconfig.c程序开始添加申明：#include "usrAPI/用户程序名.c"。
.o的链接方式：同样建立目录usrAPI，将在工程中编译生成的.o文件拷贝到usrAPI，在makefile中添加LIB_EXTRA的定义，将.o包括到VxWorks中。或者直接制作一个 usrAPI.h，在这个文件中用上面的形式申明所有出现在这些.o中的函数，然后在需要使用到这些函数的文件头部都加上#include "usrAPI/usrAPI.h"。这种方法更有利于程序的规划整齐，并且有助于日后察看函数的使用形式。最后运行已经制作好的makeall.bat，生成的VxWorks已经包含有自启动的用户程序了。
3.2 基于动态链接的自启动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%in;%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。
3.3 不同链接方法的对比
基于.c的链接方法将所有用户编写的源程序保留在BSP文件夹中，移植时不利于程序的版权保密。而在不同BSP之间用户程序的移植更是不方便，虽然这种方法不需要对makefile进行任何改动，修改的只是.c文件，比较容易理解，但仍然不推荐使用。
基于.o的链接方法保留了全部的的测试函数接口，并且移植时提供编译过的.o 文件也比提供源代码.c文件利于保密。用户源程序和BSP源程序分开，文档结构整齐，特别是对用户源程序比较庞杂的时候，使用库文件.o或者.a更加有利于文件管理。
基于.a的链接方法只保留必要的函数接口，自动优化了VxWorks的文件大小，因此将对单板机的Flash大小要求降到最低。这种方法同时使用户程序在不同BSP间的移植变得非常简单。
唯一需要注意的是，如果在生成了bootrom和VxWorks之后，希望通过更新.o来更新VxWorks中包含的用户程序，不仅需要重新运行makea.bat和重新制作usrAPI.a，还需要在命令行下输入makeclean，将VxWorks和bsp目录下(不含子目录，因此用户程序生成的.o程序不受影响)所有的*.o、*.rpo、VxWorks*、bootrom*、stdt.c、symtbl.c和depead.(bspaame)删除，然后再运行makeall.bat。因为编译时会自动检查bootrom和VxWorks的存在以及原BSP目录下文件有没有改变，如果存在并没有改变，则认为没有重新编译的必要。这样运行makeA.bat不会更新bootrom和VxWorks，而使用makeclean之后，系统检测不到bootrom和VxWorks的存在，就会重新编译了。如果觉得在命令行下输入太麻烦，希望每次都强制更新，只需要在makeall.bat程序最开头加上一行makeclean就可以了。
阅读(5502) | 评论(0) | 转发(2) |
