VxWorks Legacy Driver开发全解：卷三详析

需积分: 0 42 浏览量更新于2024-07-26 收藏 1.6MB PDF 举报

《VxWorks设备驱动开发者指南》卷三：传统驱动与迁移，是前两卷的补充，专注于讲解在VxWorks操作系统环境下Legacy Driver（传统驱动）的开发技术。该卷内容深入到VxWorks内核级编程，帮助开发者理解如何设计、实现和维护这些驱动程序，以适应各种硬件设备在嵌入式系统中的通信与控制需求。在第6.8版中，作者全面阐述了Legacy Driver的开发流程，包括但不限于以下几个关键知识点： 1. **驱动架构**：介绍VxWorks驱动程序的基本结构，如中断处理、设备描述符（DD）的管理、内存管理和I/O操作的封装。开发者需要熟悉这些基本概念以便编写出高效且兼容性良好的驱动代码。 2. **中断管理**：VxWorks支持多任务并发，中断是驱动与内核交互的重要方式。驱动开发者需掌握中断向量表的配置、中断服务函数(ISR)的编写以及中断嵌套和优先级处理。 3. **设备描述符(DD)**：DD是VxWorks中描述硬件设备特性的关键数据结构，包括设备地址、设备属性和驱动程序接口等信息。开发者需要了解如何创建、注册和注销DD，以及在设备枚举和初始化过程中如何使用它们。 4. **驱动编程模式**：针对不同类型的硬件，可能需要选择用户模式或内核模式进行驱动编写。开发者需要根据设备访问内存的特性来决定是通过系统调用还是直接硬件操作，以确保性能和安全。 5. **驱动的编译和链接**：使用特定的工具链和编译选项，如VxWorks的makefile和config文件，设置驱动程序的编译参数，确保驱动能够正确链接到内核并运行在目标平台上。 6. **驱动的测试与调试**：卷三提供了实用的调试技巧和测试方法，如使用调试器、日志记录和单元测试，以确保驱动的稳定性和功能性。 7. **迁移策略**：对于现有的Legacy Driver，章节会讨论如何将其迁移到VxWorks的新架构，包括可能遇到的问题及解决策略，以保持系统的兼容性和性能。 8. **兼容性与硬件抽象层(HAL)**：为了简化不同硬件平台间的驱动开发，VxWorks提供硬件抽象层。这部分内容会详细介绍如何利用HAL编写驱动，以及其在跨平台移植中的作用。 9. **安全性和可靠性**：驱动程序的安全性和稳定性是关键。开发者需要遵循最佳实践，处理错误情况，避免资源泄露，并确保驱动在高负载环境下的鲁棒性。《VxWorks设备驱动开发者指南》卷三为读者提供了丰富的实战经验和理论指导，旨在帮助开发者充分利用VxWorks的特性，构建高效、可靠和可维护的设备驱动程序。无论是初次接触VxWorks的开发者，还是希望优化现有驱动的专家，这一卷都是一份宝贵的参考资料。

VxWorks

Device Driver Developer's Guide, 6.8

For complex devices (for example, Ethernet devices), using a header file can

greatly improve the readability of the driver source code; putting everything in

one file can cause the source to appear cluttered, and collecting all of the hardware

specific information together into a separate file helps consolidate it rather than

allowing it to become spread out across different places in the source. If a header

file is used, it should contain the following:

■

hardware register offset values

■

hardware register bit descriptions

■

hardware DMA descriptor structure layouts

■

shortcut register access macros

■

a definition for the device-specific context structure (pointed to by pDrvCtrl in

the vxbDev structure)

If a device contains a sub-module that may be common to other devices in the same

class, you can also define the register or data structure information for the

sub-module in a separate file so that it can be used by different drivers that

incorporate support for the same sub-module.

Driver Component Description File

The component description file (CDF) for your driver allows the driver to be

configured and included in a project using standard Wind River tools (Workbench

and the vxprj command-line utility).

Wind River driver CDF files are located in:

installDir/vxworks-6.x/target/config/comps/vxWorks

And in the architecture-specific directories under this directory.

Third-party driver CDF files are located in:

installDir/vxworks-6.x/target/3rdparty/vendor/driver

By convention, driver files use the prefix 40, for example 40g64120a.cdf.

NOTE: Driver header files are typically private to a driver only. Structures or

definitions that should be shared between the driver and an API library should be

placed in a separate file.

NOTE: This section provides an overview of the CDF requirements for adding a

driver. For detailed information on CDFs and the component description

language, see the VxWorks Kernel Programmer’s Guide.

NOTE: The kernel configuration tool does not automatically search for files in the

third-party directories in:

installDir/vxworks-6.x/target/3rdparty

In order for the kernel configuration tool to be able to read the component

definitions in the CDF files, the CDF files from these directories need to be

manually copied to:

installDir/vxworks-6.x/target/config/comps/vxWorks

2 Migrating to VxBus

2.3 Porting an Existing VxWorks Driver to VxBus

In most cases, the CDF file requires that you supply a value for Component. Also,

the

_INIT_ORDER value must be set to hardWareInterFaceBusInit.

For example:

Component DRV_CLASS_NAME {

NAME DriverName

SYNOPSIS Description Of Driver

_CHILDREN FOLDER_DRIVERS

REQUIRES INCLUDE_VXBUS \

INCLUDE_PLB_BUS \

other requirements

INIT_RTN sampleDriverRegister();

INIT_AFTER INCLUDE_PLB_BUS

_INIT_ORDER hardWareInterFaceBusInit

_CHILDREN FOLDER_DRIVERS

}

Note that by default, the driver is specified as a child of the FOLDER_DRIVERS

folder. This is done by specifying the

_CHILDREN option as shown in the example:

_CHILDREN FOLDER_DRIVERS

Many drivers have configuration options. Configuration options that are specified

as parameters should be configurable from within Workbench. To do this, provide

Parameter entries for each parameter and link the parameters to your Component

with the

CFG_PARAMS keyword.

For more information on how the driver manages configuration options internally,

see the VxWorks Device Driver Developer’s Guide, Volume 1.

Driver Configuration Stub Files

Configuration stub files provide similar functionality to the CDF file, but are used

when building the VxWorks image from the BSP directory using the make

command (this is known as the bspDir/config.h build method).

In most cases, each driver requires two stub files. The stub files are named

according to the convention for your driver, with the extensions .dc and .dr.

The driverName.dc file usually contains a forward reference to the driver

registration routine, and nothing else. Use the Wind River macro

IMPORT to

declare this routine. Note that all registration routines return a void value.

The following is a sample driver .dc file:

IMPORT void sampleDriverRegister(void);

NOTE: Be sure to include the leading underscore on the keywords of the CDF file

(where shown in the example above). The underscore reverses the meaning. For

example, a

_CHILDREN entry indicates that this component (in this case, your

driver) is a child of the specified folder. If the underscore is not present, the folder

(

FOLDER_DRIVERS) is configured as a child of your driver, which is not correct.

NOTE: In general, you should build your project files using Workbench or the

vxprj command-line utility. However, the BSP build method described in this

section is required in certain development scenarios, including early BSP and

driver development. For more information on this build method, see the VxWorks

Command-Line Tools User’s Guide.

VxWorks

Device Driver Developer's Guide, 6.8

The .dr file contains a call to the driver registration routine. This call must be

surrounded by #ifdef and #endif. The macro used on the #ifdef line must match

the component name used in the CDF file (see Driver Component Description File,

p.8).

The last line must be terminated with a newline (be sure that your editor does not

strip it off).

The following is a sample driver .dr file:

#ifdef DRV_CLASS_NAME

sampleDriverRegister();

#endif /* DRV_CLASS_NAME */

Wind River driver .dc and .dr files are located in the following directory:

installDir/vxworks-6.x/target/config/comps/src/hwif

Third-party driver .dc and .dr files are located in the following directory:

installDir/vxworks-6.x/target/3rdparty/vendor

/driver

Execute the following make command in the hwif directory (see above):

> make vxbUsrCmdLine.c

This re-directs the contents of the .dc and .dr files to:

installDir/vxworks-6.x/target/config/all/vxbUsrCmdLine.c

Modifying the BSP (Optional)

This step is optional because your BSP may already be VxBus-compliant or,

depending on the device, there may be no explicit BSP support required (for

example, when working with PCI devices).

Depending on the bus type, VxBus may be able to discover your device

automatically. For example, when the device is on a PCI bus or variant of PCI,

information about the device is available from PCI configuration space. VxBus

reads this information and compares it against PCI configuration information

provided by a driver for a PCI device. If the information matches, the driver is

paired with the device.

However, with the PLB bus type, devices are not discovered automatically. In this

case, you must add an entry for your device in the hcfDeviceList[ ] array in the

BSP hwconf.c file.

NOTE: When building the VxWorks image from the BSP directory using the make

command, the vxbUsrCmdLine.c file is included (using #include) by the

installDir/vxworks-6.x/target/config/all/usrConfig.c file when the

INCLUDE_VXBUS and INCLUDE_VXB_CMDLINE macros are defined.

NOTE: Before you start working on your VxBus-enabled driver, you must make

sure that your BSP is also VxBus compliant. If your BSP is not enabled for use with

VxBus, see the VxWorks BSP Developer’s Guide.

2 Migrating to VxBus

2.3 Porting an Existing VxWorks Driver to VxBus

For easier debugging, configure your BSP so that the show routines are included.

Be sure to include the VxBus show routines in addition to the standard show

routines. For example, add the following lines in the BSP config.h file:

#define INCLUDE_SHOW_ROUTINES

#define INCLUDE_VXBUS_SHOW

Also include your own driver in config.h as follows:

#define DRV_CLASS_NAME

Verifying the infrastructure

Once you have created your driver, compiled it, added it to a library, and

configured your BSP, verify that what you have done so far is correct.

To do this, first build the VxWorks image from the BSP directory. Verify that the

driver file is included by using the nmarch command and searching for the

registration routine.

Next, verify that the CDF file is correct by starting Workbench and configuring the

VxWorks image. If everything is correct, your driver should be available in the

drivers folder (not greyed out).

Finally, boot the image and run vxBusShow( ). Your driver should show up in the

list of drivers and the target device should show up in the list of devices.

One common problem—frequently encountered when creating drivers for PLB

devices—is that the name of the driver does not match the name you provided in

the hcfDeviceList[ ] table. When this happens, the output of vxBusShow( )

displays the entry as an orphan rather than a device. If this happens, you must get

the names of the driver and device to match up before proceeding.

VxBus uses the name to match a driver to the hardware. The name is compared

using strcmp( ). Therefore, the name must be identical (the comparison is case

sensitive). Check that the driver name and the name listed in the hcfDeviceList[ ]

table in hwconf.c are identical and correct as necessary.

The second most common problem at this stage is related to the device's register

base address. For PLB devices, the first register base address must be non-null. You

can verify this by running vxBusShow(2).

NOTE: In this example, the show routines components are included for debug and

test purposes only. These components are not required for standard VxBus

systems.

NOTE: If the MODULES attribute is set in the component description, the

component is greyed out unless the module listed in the

MODULES attribute is

compiled and archived into a library, typically libdrv.a. If you opened your

VxWorks Image Project (VIP) in Workbench prior to compiling the module and

archiving it into the library, you may need to close the project and re-open it in

order to select your driver from the kernel configuration tool. This is because

Workbench caches the VxWorks kernel library module information.

VxWorks

Device Driver Developer's Guide, 6.8

This displays the full set of pRegBase[ ] entries for each device (instance and

orphan) known by VxBus. If the pRegBase[0] entry for your device is zero, correct

the problem by supplying the correct base address.

Before moving on to the next step, be sure that your device and driver are

connected to each other. To do this, look at the output from vxBusShow( ). If the

device appears as an orphan, the pairing was not successful.

2.3.3 Moving Existing Code into the New Source File

The goal of this phase is to consolidate your existing, working code into the VxBus

driver source file.

When the infrastructure for your driver is in place, the next step in porting is to

copy the existing driver code into the VxBus driver source file. Note that this

includes both the driver proper, and the BSP-specific stub file that you started with.

For this phase, you should modify the CDF file and the .dc stub file so that they

include the driver source file in the BSP or project compilation. You must do this

because many non-VxBus drivers have dependencies on macros that are provided

by a BSP file.

The .dc file that is included (using #include) in the driver source file in the BSP

looks similar to the following:

#ifdef DRV_CLASS_NAME

#include ../3rdparty/vendor/class/driverName.c

#endif /* DRV_CLASS_NAME */

The .cdf file that is included (using #include) in the driver source file in the BSP

looks similar to the following:

Component DRV_CLASS_NAME {

NAME DriverName

SYNOPSIS Description Of Driver

_CHILDREN FOLDER_DRIVERS

REQUIRES INCLUDE_VXBUS \

INCLUDE_PLB_BUS \

other requirements

CONFIGLETTES ../3rdparty/vendor/class/driverName.c

INIT_RTN sampleDriverRegister();

INIT_AFTER INCLUDE_PLB_BUS

_INIT_ORDER hardWareInterFaceBusInit

_CHILDREN FOLDER_DRIVERS

}

NOTE: In some cases, you may not want to supply the register base address in

hwconf.c. If this is the case for your driver, use a non-null value like

ERROR or

TRUE as the register base address value, both of which are non-null. If you choose

this option, your driver must not attempt to read or write registers using the VxBus

NOTE: Usually, the driver proper and the BSP-specific stub file can go in the same

file without trouble. However, you should verify that there are no

LOCAL routines

LOCAL data variables with the same name in the two files. If there are, make

whatever modifications are necessary and re-verify the non-VxBus driver.

剩余210页未读，继续阅读

jack-csdn

粉丝: 0
资源: 3

VxWorks Legacy Driver开发全解：卷三详析

vxworks device driver developers guide卷二

vxworks device driver developers guide vol2 6.6

vxworks-device-driver-developers-guide

vxworks_device_driver_developers_guide_6.8

vxworks-device-driver-developers-guide-vol 驱动编程

vxworks_device_driver_developers_guide_6.4.pdf

vxworks_device_driver_developers_guide_6.2.pdf

vxworks_device_driver_developers_guide_vol3_6.7.ra_vxworks bsp

vxworks_device_driver_developers_guide_vol3_6.6.pdf

vxworks_device_driver_developers_guide_vol2_6.8

最新资源