发布时间 : 星期四 文章VxWorks kernal programmers guide更新完毕开始阅读73f45dfea0116c175f0e48a7
MSG_Q_ID myMsgQId; /* MsgQ ID to send/receive messages */ STATUS initializeFunction (void) {
if ((myMsgQId = msgQInitialize (myMsgQ, 100, 16, options)) == NULL) return (ERROR); /* initialization failed */ else
return (OK); }
更多信息，参考API reference for msgQLib。关于消息队列通用信息，参考7.7 Message Queues。
4.6.7 看门狗定时器的静态实例化
VX_WDOG宏在编译时声明一个看门狗定时器。使用一个参数，看门狗定时器的名字。wdInitialize( )函数用于初始化看门狗定时器和使能使用。相同的看门狗名必须用于宏和函数。如：
#include
VX_WDOG(myWdog); /* declare the watchdog */
WDOG_ID myWdogId; /* watchdog ID for further operations */ STATUS initializeFunction (void) {
if ((myWdogId = wdInitialize (myWdog)) == NULL) return (ERROR); /* initialization failed */ else
return (OK); }
更多信息，参考API reference for wdLib。关于消息队列的通用信息，参考8.4 Watchdog Timers。
4.7 内核应用和内核组件需求
VxWorks是一个高配置操作系统。当内核应用模块独立于操作系统编译（参考4.9 Building Kernel Application Modules），编译过程不能确定是否应用上的VxWorks实例最终运行，因为，要保证VxWorks内核包含应用所需的所有组件（如网卡和文件系统等）。因此，应用代码检查内核设备不存在的错误提醒（也就是说，检查API调用的返回值）和正确的回复比较有用。
当内核应用模块链接到操作系统时，编译系统产生和丢失组件相关的错误。Workbench和vxprj命令行工具也可以提供为重新配置VxWorks进行依赖检查的机制。
4.8 内核应用和内核组件需求
4.9 编译内核应用模块
VxWorks内核应用可以用Workbench或用命令行编译（命令行环境包括一组有用的默认makefile规则）。关于Workbench和命令行编译环境的用法，参考Wind River Workbench by Example guide和VxWorks Command-Line Tools User’s Guide。
提醒：VxWorks内核应用必须针对运行的系统类型编译。针对UP VxWorks系统编译，
针对SMP VxWorks编译，针对基于版本库创建的VxWorks系统，版本库基于VSB工程（UP或SMP），二进制不兼容。注明loader拒绝一个内核模块若和加载的系统不兼容，控制台会输出一个错误信息，并设置errno为S_loadLib_INCOMPATIBLE_MODULE。
4.10 下载内核应用对象模块到目标机
内核应用对象模块可以从Workbench或内核shell中下载。一旦一个模块加载到目标内存，模块中的任何子函数会被触发，任务发起，模块使用的调试工具等。通常使用启动函数来运行应用比较有用。（参考4.4 Kernel Application Structure）。
关于使用内核shell和内核loader信息，参考16.2 Kernel Shell和16.3 Kernel Object-Module Loader。关于使用Workbench更多信息，参考Wind River Workbench by Example guide。
4.11 链接内核应用对象模块到VxWorks
VxWorks内核应用可以使用Workbench或命令行开发工具链接到VxWorks。关于使用Workbench和命令行编译环境信息，参考Wind River Workbench by Example guide和VxWorks Command-Line Tools User’s Guide。
4.12 配置VxWorks自动运行应用程序
VxWorks可以配置为在启动时自动启动内核应用。这样做，执行如下步骤： 1.配置INCLUDE_USER_APPL组件到VxWorks中；
2.在应用的入口点usrAppInit( )函数中增加调用，在installDir/vxworks-6.x/target/proj/projDir/usrAppInit.c文件中。
假如，应用入口点函数myAppStartUp( )启动所有应用需要的任务，你需要在usrAppInit( )函数中增加调用如下：
void usrAppInit (void) {
#ifdef USER_APPL_INIT
USER_APPL_INIT; /* for backwards compatibility */ #endif
myAppStartUp(); }
3.链接基于内核应用对象模块到内核镜像（参考4.11 Linking Kernel Application Object Modules with VxWorks）。
4.13 镜像大小考虑
系统镜像大小通常要重点考虑，尤其是当内核应用模块链接到操作系统后。这是真实的是否镜像被一个boot loader加载或自启动（参考2.7 VxWorks Image Types）。
提醒：对于基于ROM镜像，确保ROM_SIZE配置参数影响ROMs使用的容量。
4.13.1 boot loader和可下载镜像
通常，VxWorks boot loader代码被拷贝到RAM的一个起始地址上面的常量地址RAM_HIGH_ADRS，boot loader轮流拷贝可下载系统镜像到RAM_LOW_ADRS位置。这些常量的值是体系结构独立的，但是在任何情况下系统镜像不能超过两个常量间的空间。否则系统会覆盖boot loader代码，当下载时，潜在杀死启动进程。
为了帮助避免这个除夕，上一个命令执行当编译一个新的Vxworks镜像为vxsize，表示
新可执行镜像大小和ROM中预留了多少空间：
vxsize 386 -v 00100000 00020000 vxWorks
vxWorks: 612328(t) + 69456(d) + 34736(b) = 716520 (235720 bytes left)
(In this output, t stands for text segment, d for data segment, and b for bss.)
确信RAM_HIGH_ADRS小于LOCAL_MEM_SIZE。若新镜像太大，vxsize产生一个警告。这种情况下，你应该重新配置boot loader来拷贝启动ROM代码到足够的内存地址位置，通过增加config.h文件中RAM_HIGH_ADRS值，和BSP的makefile（两个值也一致）。之后重新编译boot loader。更多信息，参考Reconfiguring Memory Layout for a Persistent Memory Region。
4.13.2 自启动镜像
对于自启动镜像，驻留ROM VxWorks 系统的数据段加载到RAM_LOW_ADRS（在makefile中定义）以最小化内存碎片。
对于有限内存的CPU板（小于1M RAM），确信RAM_HIGH_ADRS小于LOCAL_MEM_SIZE，有足够的空间来容纳数据段。注明RAM_HIGH_ADRS定义在BSP makefile和中（要一致）。
5 C++开发
5.1 介绍
这一章提供了VxWorks系统下使用风河和GNU工具链进行C++开发相关信息。 警告：风河编译器C++和GNU C++库文件不兼容。
注明：本章提供了VxWorks内核有的相关设施信息。关于实时进程相关信息，参考VxWorks Application Programmer’s Guide相关章节。
5.2 配置C++到VxWorks
默认，VxWorks仅包括mini C++支持。你可以通过增加如下组件支持C++功能： INCLUDE_CTORS_DTORS
默认包含在内核中，确保编译器产生的初始化函数，包括C++静态对象的初始化，在内核启动时调用。
INCLUDE_CPLUS
包括基本的C++应用支持。通常和INCLUDE_CPLUS_LANG混合使用。 INCLUDE_CPLUS_LANG
包含C++语言功能支持，如new, delete和异常处理。 INCLUDE_CPLUS_IOSTREAMS 包括所有的库功能。
INCLUDE_CPLUS_DEMANGLER
包括C++命令，在使用内核shell loader时非常用于，因为它提供用于内核shell特征表查询返回命令特征名。若同时包含INCLUDE_CPLUS和INCLUDE_SYM_TBL组件，这个组件被默认增加。
5.3 C++代码需求
任何使用C++的VxWorks任务必须用VX_FP_TASK选项发起。默认，从主机工具发起任务（风河shell）默认使能VX_FP_TASK。
警告：当使用VX_FP_TASK选项发起使用C++的任务失败时，可能很难调试，在运行时产生不可预见的浮点数寄存器破坏。
若你从你的C代码中引用一个（非重载，全局）C++特征，你必须使用extern \通过原型C链接：
#ifdef __cplusplus
extern \#else
void myEntryPoint (); #endif
你也可以使用这个语法来在C++代码中访问C特征。VxWorksＣ特征自动存在在C++代码中，因为VxWorks头文件使用这种声明机制。
每个编译器有自身的C++库和C++头（如iostream和new）。C++头位于编译器安装目录，不是installDir/vxworks-6.x/target/h中。不需要做什么就可以使能编译器找到这些头。
注： VxWorks 5.5之前发布版本，风河推荐使用-nostdinc标志。目前的发布版本不需要使用这个标志，防止编译器找不到头文件，如stddef.h。
5.4 在信号处理和ISRs中使用C++
小心在信号处理和ISRs中使用C++代码。相关信息，参考8.2.5 Signal Handlers和8.3.3 Caveats With Regard to Writing ISRs。
5.5 在DKM工程中使用C++
下载到VxWorks内核中的C++代码应该链接到一个单一下载对象模块中。也必须被一直使用，任何COMDAT或已经连接的部分会销毁。VxWorks为在可下载模块中调用静态构造和析构函数提供了几种措施。
警告：风河编译器C++和GNU C++库文件是不兼容的。用C++写的DKM必须用VxWorks使用的编译来编译。 5.5.1 使用一个单一C++模块
VxWorks loader 仅支持self-contained的C++模块。一个自包含的C++模块是一个不能使用来之其它C++模块的类，它的类也不能被其它C++模块使用。尤其，一个模块必须包含自身标准库拷贝，或不使用C++标准库。
为了生产自包含模块，所有下载的C++对象文件应于被链接到一个单一可下载对象模块。
卸载一个不是自包含的C++模块可能会导致来之其他模块创建对象的空引用到卸载模块中的数据结构。尤其，若标准库流部分来之后面卸载的一个模块的初始化是会出现的。这种情况下，任何更进一步的iostreams的使用会伴随一个内核异常失败（访问无效的地址）。
警告：C++对象文件必须链接到一个DKM模块。
关于内核loader的信息，参考16.3 Kernel Object-Module Loader。
5.5.2 Munching 一个C++应用模块
在一个C++模块加载到VxWorks内核前，必须经历一个附件主机处理步骤，由于历史原因，称为munching。Munching执行如下任务： 初始化静态对象支持
确保为所有的静态对象在C++运行时以正确的顺序调用构造和析构函数。
对于风河编译器，自动销毁COMDAT部分；对于GUN编译器，自动销毁linkonce。