Responding to Changes in Device Parameters. Wind River VxWorks

VxWorks is an operating system for real-time and embedded applications. The VxWorks Device Driver Developer's Guide is a document that provides developers with the information they need to develop device drivers for the VxWorks operating system. This document covers the fundamentals of writing device drivers, as well as provides class-specific information for various driver classes. It also includes information on migrating legacy model drivers to the VxBus model.

PDF

Document

VxWorks

Device Driver Developer's Guide, 6.7

In this table, the rtl8169VxbEnd driver declares that it supports three parameters, named rxQueue00, txQueue00, and jumboEnable. When the driver registers with

VxWorks, it provides a pointer to these parameters as part of its driver registration data structure. For example:

LOCAL struct vxbPciRegister rtgDevPciRegistration =

{

/* . */ rtgParamDefaults

/* . */

}

/* pParamDefaults */

};

Using this information, VxWorks stores the driver's default values for each of its parameters. Unless the parameters are changed by the BSP or application, the default driver values are the values that are returned when the driver calls

vxbInstParamByNameGet( )

There are two methods that can be used to override the default value of a parameter for a driver:

■

The BSP can provide a different default value in its hwconf.c file. or

■

A call can be made to vxbInstParamSet( ), to change the value of the parameter at runtime.

When the BSP provides a different default value for a parameter, the BSP default value replaces the driver-provided value for the parameter. This replacement occurs as soon as the driver registers with VxWorks, therefore there is no period of time where the driver default can be returned using vxbInstParamByNameGet( ).

In addition to the BSP override method, the default value of a parameter can also be changed at runtime through a call to vxbInstParamSet( ). vxbInstParamSet( ) can be used to modify the default values for a driver parameter.

For complete information on vxbInstParamByNameGet( ) and

vxbInstParamSet( )

, see the reference entries for these routines.

Responding to Changes in Device Parameters

When a call is made to vxbInstParamSet( ), the parameter value for a driver is altered. However, unless special steps are taken by the device driver, the updated value may not be noticed by the driver. For example, consider the following steps:

3 Device Driver Fundamentals

3.6 Services Available to Drivers

The driver registers with VxWorks, its default parameter values are stored by

VxWorks.

The driver is bound to a device, creating a hardware instance. The driver uses the stored values for its parameters to configure the instance.

An application calls vxbInstParamSet( ) to change the parameters used by the driver. However, because the driver is already initialized when

vxbInstParamSet( )

occurs, the call to vxbInstParamSet( ) has no effect within the driver.

To address this scenario, device drivers are given the option to be informed of any changes to their parameter list that occur through a call to vxbInstParamSet( ).

VxWorks provides a special driver method that can be implemented for any device driver that needs to monitor changes to its parameter list. To implement this method in your driver, the driver must publish the {instParamModify}( ) driver method. If the driver publishes this method, the method's callback function is invoked whenever a change occurs to the driver parameters.

Support for the {instParamModify}( ) method is optional, and is not required for most drivers. In practice, driver parameters are generally expected to be overridden by the BSP hwconf.c file, rather than at runtime.

3.6.2 Memory Allocation

When a VxBus model device driver is connected to a device to form an instance, the driver typically stores information about this instance in a memory-resident data structure. This data structure can be declared statically within the driver source file, or the driver can allocate the structure dynamically at runtime using one of the available memory allocation libraries offered by VxWorks. For example, a simple driver might declare the following data structure to allocate memory for its data structures:

LOCAL simpleDriver_t simpleDriverInstanceStore[MAX_INSTANCES];

While a driver can use this method to reserve the memory for its instance data, this method is not recommended for two reasons:

■

The number of simultaneous instances that the driver can support is artificially restricted.

When the driver is used less than the maximum number of instances, the memory for the unused instances is wasted.

Key features

Fundamentals of writing device drivers
Class-specific information for various driver classes
Information on migrating legacy model drivers to the VxBus model
Real-time performance
Code size
Driver flexibility
Code maintainability
Code readability
Driver Configurability

Frequently asked questions

VxWorks is an operating system for real-time and embedded applications.

The VxBus driver model is the preferred method for developing new device drivers for VxWorks.

VxWorks supports a variety of driver classes, including serial drivers, storage drivers, network interface drivers, non-volatile RAM drivers, timer drivers, DMA controller drivers, bus controller drivers, USB drivers, interrupt controller drivers, and multifunction drivers.

The primary goal for most VxWorks drivers is real-time performance of the target system as a whole. Other important design goals include memory footprint, driver flexibility, code maintainability, code readability, and driver configurability.

User questions

James A.

How can a PCIe device be registered and enabled using VxWorks drivers?

To register and enable a PCIe device using VxWorks drivers, the process generally involves: Driver Registration: Using vxbDevRegister() to register the driver with VxBus, populating vxbDevRegInfo with device ID, bus ID, driver name, and function pointers. Hardware Discovery: Bus controller drivers are responsible for discovering devices and configuring downstream devices. Device Matching: VxBus verifies the driver's registered bus type matches the device; for PCIe, device ID and vendor ID are commonly used. Interrupt Enable: After registration, vxbIntEnable() is used to enable the delivery of a device interrupt. Resource Allocation: Access to hardware registers requires finding the base address and mapping it using vxbRegMap(), then using vxbRead*() and vxbWrite*() functions.

Jennifer T.

What does 'no-map' signify in the context of device drivers and how can such issues be addressed?

In general computing and device driver contexts, 'no-map' typically refers to a situation where a memory region or hardware register address space is not successfully mapped into the CPU's addressable memory. This can lead to issues where the device driver is unable to read from or write to the hardware registers, making communication with the device impossible.

Common reasons for a 'no-map' situation can include incorrect base addresses, missing or incorrect memory mapping configuration (e.g., in the Board Support Package or BSP), hardware issues, or permissions. To address such an issue, one would generally need to verify the hardware configuration, review the BSP's memory mapping setup, and ensure the device driver is using the correct addresses.

James C.

How is an Interrupt Service Routine (ISR) connected to a device driver in VxWorks?

In modern VxWorks, device drivers use operating system services (like vxbIntConnect()) to connect ISRs, rather than the older intConnect() method. The number of interrupt sources the device generates must be known to connect the appropriate ISR to each hardware interrupt source.

James C.

How can the impact of Interrupt Service Routines (ISRs) on system performance in VxWorks be minimized?

ISRs should be as short as possible to minimize system interrupt latency. isrDeferLib can be used to defer any lengthy processing to the task level.

James C.

What VxWorks operating system services are available for deferring work from an ISR to a task?

isrDeferQueueGet() returns a handle to an ISR deferred queue, and isrDeferJobAdd() adds a data structure describing the deferred work to the queue. This work is executed at the task level after the ISR completes.

James A.

What is the purpose of the vxbDevRegister() function in VxWorks?

The vxbDevRegister() function is used by a driver to notify VxWorks that the driver is available and to provide required information about the driver during the driver registration phase.

Patricia Y.

What is the function of isrDeferJobAdd?

isrDeferJobAdd() adds a data structure describing deferred work to be performed onto an ISR deferral queue. This work is performed after the ISR enqueuing the work terminates and task processing resumes.

James C.

What are interrupt indexes and how are they used within VxWorks?

Each interrupt signal generated by a device is identified by an interrupt index. Most devices generate a single interrupt, identified as interrupt index 0. More complex devices have multiple interrupt signals, assigned incrementing interrupt indexes starting from 0.