VxWorks 7程序员指南

需积分: 5 33 浏览量更新于2024-07-01 收藏 3.75MB PDF 举报

"VxWorks 7 Programmer's Guide SR0620.pdf 是一份由Wind River Systems公司编写的关于VxWorks 7操作系统的程序员指南。该文档详细介绍了VxWorks 7的编程技术和最佳实践，版权归属Wind River Systems，所有权利保留。VxWorks是Wind River公司的注册商标，同时文档中提到了其他多个与Wind River相关的商标。这份指南可能包含了来自第三方的软件许可，并在Wind River的下载和安装门户Wind Share上提供了相关通知。此外，Wind River可能会引用第三方文献或提供链接到第三方网站，以提供更多信息。" 在VxWorks 7程序员指南中，你可以了解到以下关键知识点： 1. **VxWorks操作系统**：VxWorks是一款实时操作系统（RTOS），被广泛用于嵌入式系统开发，特别适用于需要高度可靠性和高性能的领域，如航空、航天、通信和医疗设备等。 2. **实时性**：VxWorks 7的核心特性之一就是其强大的实时性能，它允许开发者精确地控制任务调度和中断处理，以满足严格的实时要求。 3. **编程接口和API**：VxWorks 7提供了丰富的编程接口，包括任务管理、内存管理、互斥量、信号量、消息队列等，使得开发者可以高效地进行多线程编程。 4. **软件组件模型**：VxWorks 7引入了软件组件模型，这是一种模块化的设计，便于软件组件的重用、升级和维护。 5. **网络支持**：VxWorks 7支持各种网络协议栈，包括TCP/IP，UDP，IPv4/IPv6，以及HTTP，FTP等，适合于构建网络化的嵌入式系统。 6. **开发环境**：Wind River的集成开发环境（IDE）Tornado或者Helix IDE为VxWorks 7提供了完善的开发、调试和测试工具链。 7. **安全性与认证**：VxWorks 7考虑了安全性，可能包含了一些安全特性，如安全启动、安全更新机制等，以满足不同行业的安全标准和认证需求，例如DO-178C（航空电子软件）和IEC 61508（工业自动化）。 8. **设备驱动开发**：指南将涵盖如何为VxWorks 7编写和管理设备驱动，以便充分利用硬件资源。 9. **移植和兼容性**：VxWorks 7可能支持多种处理器架构和板级支持包（BSP），方便软件在不同硬件平台上移植。 10. **诊断和调试**：文档会介绍如何利用内置的诊断工具和调试器进行问题排查和优化。通过深入学习这份VxWorks 7程序员指南，开发者可以掌握VxWorks 7的精髓，从而更高效地开发、测试和部署嵌入式系统。

simply requires an entry point function that starts all the tasks required to get the application

running.

Application Entry Point

The entry-point function performs any data initialization that is required, and starts all the tasks

that the running application uses.

NOTE: If your kernel application includes a main( ) function, do not assume that it will

start automatically. Kernel application modules that are downloaded or simply stored in

the system image must be started interactively (or be started by another application that is

already running). The operating system can also be configured to start applications

automatically at boot time (see aUsing userAppInit() to Run Applications Automatically

on page 12).

For example, a kernel application might have a function named myAppStartUp( ), which could

look something like this:

void myAppStartUp (void)

{

runFoo();

tidThis = taskSpawn("tThis", 200, 0, STACK_SIZE,(FUNCPTR) thisFunction,

0,0,0,0,0,0,0,0,0,0);

tidThat = taskSpawn("tThat", 220, 0, STACK_SIZE,(FUNCPTR) thatFunction,

0,0,0,0,0,0,0,0,0,0);

tidAnother = taskSpawn("tAnother", 230, 0,STACK_SIZE,(FUNCPTR) anotherFunction,

0,0,0,0,0,0,0,0,0,0);

return (OK);

}

For information about VxWorks tasks and multitasking, see Tasks and Multitasking on page 94.

For information about working with C++ see C++ Support on page 89.

Automatic Invocation of Initialization and Termination Functions

If you are going to download your kernel application module to VxWorks at runtime, you can

have the loader start it automatically by implementing a _VxModuleAutoInit( ) function as the

entry point, and using the LOAD_CALL_INIT_AUTO option with loadModuleAt( ). The

LOAD_CALL_INIT_MANUAL option is also provided so that the module can be loaded

without calling the initialization function automatically.

Similarly, you can implement a _VxModuleAutoTerm( ) function that is automatically invoked

when the module is unloaded using the unldByModuleId( ) function with the

UNLD_CALL_TERM_AUTO option.

For more information, see the loadLib and unldLib API reference entries.

VxWorks 7

Programmer's Guide, SR0620

VxWorks Header Files

Many kernel applications make use of VxWorks operating system facilities or utility libraries.

This usually requires that the source module refer to VxWorks header files.

VxWorks System Header Files

VxWorks header files supply ANSI C function prototype declarations for all global VxWorks

functions. VxWorks provides all header files specified by the ANSI X3.159-1989 standard.

VxWorks system header files are copied to the VSB project directory, below vsbProjectDir/krnl/h.

VxWorks Header File: vxWorks.h

The header file vxWorks.h must be included first by every kernel application module that uses

VxWorks facilities. It contains many basic definitions and types that are used extensively by other

VxWorks modules. Many other VxWorks header files require these definitions. Include

vxWorks.h with the following line:

#include <vxWorks.h>

VxWorks Nested Header Files

Some VxWorks facilities make use of other, lower-level VxWorks facilities. For example, the tty

management facility uses the ring buffer library. The tty header file tyLib.h uses definitions that

are supplied by the ring buffer header file rngLib.h.

It would be inconvenient to require you to be aware of such include-file interdependencies and

ordering. Instead, all VxWorks header files explicitly include all prerequisite header files. Thus,

tyLib.h itself contains an include of rngLib.h. (The one exception is the basic VxWorks header file

vxWorks.h, which all other header files assume is already included.)

Generally, explicit inclusion of prerequisite header files can pose a problem: a header file could

get included more than once and generate fatal compilation errors (because the C preprocessor

regards duplicate definitions as potential sources of conflict). However, all VxWorks header files

contain conditional compilation statements and definitions that ensure that their text is included

only once, no matter how many times they are specified by include statements. Thus, a kernel

application module can include just those header files it needs directly, without regard to

interdependencies or ordering, and no conflicts will arise.

VxWorks Private Header Files

Some elements of VxWorks are internal details that may change and so should not be referenced

in a kernel application. The only supported uses of a module's facilities are through the public

definitions in the header file, and through the module's function interfaces. Your adherence

ensures that your application code is not affected by internal changes in the implementation of a

VxWorks module.-

2 Kernel Applications

VxWorks

Header Files

deletion, in turn, involves invalidation of the object, and then return of the memory to the system.

Object creation and deletion are both dependent on dynamic memory allocation, usually with the

malloc( ) andfree( ) functions.

Applications using dynamic instantiation must therefore account for the possibility that the

system may run out of memory and that it may not be able to create the object (and resort to

some suitable error recovery process or abort). In addition, dynamic allocation is a relatively slow

operation that may block the calling task, and make system performance less deterministic.

Also in contrast to static instantiation, dynamic instantiation can be accomplished with a single

function call (for example, taskSpawn( ), semBCreate( ), and so on).

The code examples that follow illustrate the difference between coding dynamic and static

instantiation (but do not use any VxWorks object instantiation macros).

Dynamic Instantiation Code

struct my_object * pMyObj;

...

pMyObj = (struct my_object *) malloc (sizeof (struct my_object));

if (pMyObj != NULL)

{

fooObjectInit (pMyOjb);

return (OK);

}

else

{

/* failure path */

return (ERROR);

}

Static Instantiation Code

struct my_object myObj;

...

fooObjectInit(&myOjb);

/* myObj now ready for use */

Kernel Objects That can be Instantiated Statically

The following kernel objects can be instantiated statically:

• kernel tasks

• semaphores

• message queues

• watchdog timers

For detailed information, see

Task Creation and Activation on page 108, Semaphore Creation

and Use on page 134, Message Creation and Use on page 150, and Watchdog Timers on page

236.

Static Instantiation and Code Size

Compile-time declaration of objects does not occupy any space in an executable file, in a

VxWorks image, or in storage media (such as flash memory). If an object is declared at compile

time but not initialized, the compiler places it in the un-initialized data (bss) section. Un-

initialized data is required by the ANSI C standard to have a value of zero.

2 Kernel Applications

Static

Instantiation of Kernel Objects

While un-initialized data contributes to the run-time memory footprint, so does dynamic

allocation. In either case, the memory footprint would be the same.

Advantages of Static Instantiation

Static instantiation of kernel objects provides several advantages over dynamic instantiation:

• Static instantiation of objects is faster and more deterministic.

• Application logic is simpler because it does not have to account for the possibility that

dynamic allocation may fail.

• Static declaration of objects cannot fail, unless the program itself is too large to fit into system

memory.

Applications and Static Instantiation

Static instantiation of kernel objects provides notable advantages to real-time applications, and

most applications can make use of static instantiation to some degree. Most applications require

that some objects be available for the lifetime of their execution, and that they never be deleted.

These objects can therefore be statically instantiated. Using static instantiation whenever possible

makes applications more robust, deterministic, and fast.

NOTE: Static instantiation should only be used with kernel applications. It is not designed

for use with RTP (user-mode) applications.

Scope Of Static Declarations

Kernel objects are usually declared as global variables because the objects IDs are usually used

for inter-task communication and synchronization. However, they need not be global. An object

declaration can also be done at function scope provided the object stays in a valid scope for the

duration of its use.

Caveat With Regard to Macro Use

In order to ensure proper macro expansion, the task instantiation macros must use a backslash

character if the declaration or call that they implement is longer than one line. For example, the

following ensures that the static instantiation of a task with the VX_TASK_INSTANTIATE

macro will be handled properly by the compiler:

myTaskId = VX_TASK_INSTANTIATE(myTask, 100, 0, 4096, pEntry, 0,1,2,3,4,5,6,7,8,9);

Macro use is described in detail in Task Creation and Activation on page 108,Semaphore

Creation and Use on page 134, Message Creation and Use on page 150, and Watchdog Timers

on page 236.

Boot-Time Hook Function Facility

VxWorks hook function stubs that are called at specific points in the boot process can be used to

add your own boot-time functionality or test code. The stubs allow you to add code without

VxWorks 7

Programmer's Guide, SR0620

剩余543页未读，继续阅读

ppcust

粉丝: 38
资源: 725

VxWorks 7程序员指南

VxWorks__7_Programmer_s_Guide.pdf

VxWorks_7_Sockets_Programmer_s_Guide__SR0620.pdf

vxworks_7_tftp_programmers_guide_sr0620.pdf

VxWorks_7_Configuration_and_Build_Guide__SR0620.pdf

VxWorks_7_vxsim_BSP_Supplement_Guide__SR0620.pdf

VxWorks_7_PowerPC_Architecture_Guide__SR0620.pdf

VxWorks_7_qsp_ppc_BSP_Supplement_Guide__SR0620.pdf

vxworks_7_regression_test_suite_users_guide_sr0620.pdf

VxWorks_7_fsl_mpc82xx_BSP_Supplement_Guide__SR0620.pdf

VxWorks_7_fsl_p3p4p5_BSP_Supplement_Guide__SR0620.pdf

最新资源