Hints for Working with Hardware

< BACK  NEXT >

[oR]

Working with new hardware can be a real challenge. Hardware engineers follow a different design methodology than do software engineers. (Consider the user interface on a VCR.) The following hints may help make it easier to work with a new piece of hardware.

Learn about the Hardware

Before starting a new driver, learn as much as possible about the hardware itself. Most of the information needed should be in the hardware documentation. At the very least, ensure that information is available for

• bus architecture

• control registers

• error and status reporting

• interrupt behavior

• data transfer mechanisms

• device memory

BUS ARCHITECTURE

The hardware's bus architecture will have a big impact on the design of the driver. Auto recognition and configuration information must be clear. New drivers will be expected to participate in the Plug and Play mechanisms offered by Windows 2000.

CONTROL REGISTERS

The size and addressing scheme of the device's registers must be known. The purpose of each register and contents of any control, status, and data registers must be fully described. Odd behavior must be identified. For example:

• Some device registers may be read-only or write-only.

• A single register address may perform different functions on a read than it does on a write.

• Data or status registers may not contain valid information until some fixed time interval after a command is issued.

• Register access in a specific order may be required.

ERROR AND STATUS REPORTING

Determine any protocols used by the device for reporting hardware failures and device status.

INTERRUPT BEHAVIOR

Find out exactly what device conditions cause the hardware to generate an interrupt, and whether the device uses more than one interrupt vector. If working with a multidevice controller, interrupts may come from the controller itself, and there must be a mechanism to identify the actual device that wants attention.

DATA TRANSFER MECHANISMS

Drivers for programmed I/O devices are very different from DMA drivers. Some devices are capable of doing both kinds of I/O. In the case of a DMA device, find out if the DMA mechanism is bus master or bus slave, and whether there are any limitations on the range of physical buffer addresses it can use.

DEVICE MEMORY

If the device uses dedicated memory, find out how to access it. It could be mapped at a fixed physical location or there may be a register that must be initialized, pointing to the mapped address.

Make Use of Hardware Intelligence

Some peripherals contain their own processors that perform both diagnostic and device control functions. The processor may be running under the control of some firmware, or it may be possible for the driver itself to download code to on-board RAM at initialization time.

When working with a smart peripheral, it makes sense to take full advantage of the device's intelligence. Proper use of hardware features can result in significantly better driver performance and improved diagnostic capabilities.

Test the Hardware

New hardware is seldom delivered bug-free. Hardware should be tested early and tested often. Besides providing an opportunity to discover design errors, it also provides a discovery process for the device author to learn about a device's behavior.

BASIC TESTS

Make sure the device and any associated cables are all compatible with the development machine. Power up everything and try a simple boot. At a gross level, this ensures that the device isn't interfering with anything else in the box.

STANDALONE TESTS

If possible, write some standalone code that tests the board and any firmware it may contain. This will usually be a program that runs without the benefit of an operating system, or perhaps under DOS. With luck, the hardware vendor will provide some sort of exerciser for this purpose.

Finally, remember to test any on-board diagnostics by putting the hardware into an illegal state. The on-board firmware should detect and report the problem.

< BACK  NEXT >