Windows 98 refines data acquisition.
Windows 98, expected to hit the market by this summer, features a new driver model also used in Windows NT 5.0. Backward compatible with Windows 95, it also provides support for the new external buses, the Universal Serial Bus (USB), and Firewire (IEEE 1394).
The Windows 95 operating system relies on the VxD driver model. VxD programming is operating system- and microprocessor-dependent because it requires a combination of assembler and C/C++ programming. Also, VxD programming is strictly in the kernel, allowing a poorly written device driver to crash the entire operating system.
Current VxD drivers work in both Windows 95 and Windows 98, but VxD is not compatible between Windows 95 and Windows NT. Developers need to create different drivers for the two operating systems, increasing time-to-market and code-maintenance costs.
These compatibility issues also mean that if only Windows 95 and 98 markets are targeted, the VxD model is appropriate. If Windows 95, Windows 98, and Windows NT 5.0, are targeted, the VxD model for Windows 95 and WDM for the Windows 98 and NT 5.0 should be used.
The Win32 Driver Model, or WDM, is introduced in Windows 98. Based on the Windows NT driver model, it provides binary driver compatibility between Windows 98 and the upcoming Windows NT 5.0. Data-acquisition developers should be able to program their entire driver in C/C++.
To reduce driver-related system crashes, Microsoft developers have introduced a set of device classes to Windows 98 which reuse much of the complex operating system-specific code. With them, developers can focus on the value-added sections of code and write "minidrivers" for their devices, separating device, protocol, and bus-class driver functions. Some minidrivers can be written in user mode. In the event of a user-mode programmer error, the error should affect only the specific device driver instead of crashing the operating system.
At present, there are device classes for audio, video, human-interface devices (mice, keyboards, and monitors), communications, and printers. There are no device classes for data-acquisition devices. It's up to data acquisition developers to either try to fit their driver code around one of the existing classes or to develop their device driver from scratch.
Microsoft and Intel are calling for the removal of the ISA, parallel, and serial buses from computers over the next few years, leaving only the USB, 1394, and PCI buses. Developers have planned to replace the ISA and serial buses with the USB, while IEEE 1394 is expected to replace the parallel port and SCSI. This will reduce the cost of producing motherboards and minimize the number of buses users will need to deal with.
USB and 1394 are hot-pluggable, plug-and-play buses. Users will no longer need to configure I/O addressing, interrupts, and DMA. Users can plug their USB or 1394 device into the computer at any time, and the device should automatically be configured.
The Universal Serial Bus is the first of the new external buses to ship on personal computers. The USB architecture transfers data via frames at the rate of one frame/msec. USB supports two different device speeds: 1.5 Mb/sec (low speed) and 12 Mb/sec (full speed). Each frame contains data from any or all attached USB devices up to 127 physical devices.
Developers should note that the cable length maximum is 5 m, which may hinder data acquisition devices that require placement farther from the computer.
Most computers start with two USB connectors; however, vendors are currently developing hubs to accommodate more devices. The monitor will be one common place for a hub.
USB supports only host-based communication, so all read and write operations must begin with a request from the host. Four forms of transfers exist:
* Isochronous transfers
* Interrupt transfers
* Control transfers
* Bulk transfers
Isochronous and interrupt transfers can reserve up to 90% of the USB bandwidth, while, in theory, control transfers can reserve up to 10%. Bulk transfers occur during any "free time," and may be split among multiple frames.
The isochronous transfer method operates in real time and is considered highest priority. A portion of the USB bandwidth may be reserved in advance for dedicated isochronous transfers. This method is used when receiving data at a regular time interval (for example, telephony or video) is more important than data integrity. There is no error correction or recovery; therefore, communication problems may cause "packet dropping"--a permanent loss of data.
The interrupt transfer method has the next highest priority. Since USB supports only host-initiated transfers, interrupt transfers poll the device for data. If the device has no interrupt data to send, it returns a "no acknowledge" (NACK) message. The interrupt transfer method guarantees delivery by attempting delivery until it's successful.
Control transfers provide USB control access and single-point transmission. Each device has at least one default control pipe which allows configuration and control access to the USB microcontroller. Driver developers may use another control pipe for single-point communication with the device's firmware. Control transfers contain two or three stages: setup, data, and status, where each stage requires a different frame. Error detection and recovery are possible with the control transfers, but are generally viewed as a fatal condition.
Bulk transfers allow the transmission of larger amounts of data, up to 64 bytes of data/data packet, with multiple packets/frame. During a bulk transfer, every packet is the maximum specified size, except for the last packet. Bulk transfers are treated with the lowest priority and will occur only when there is unallocated bus bandwidth. Error detection and recovery are available with bulk transfers.
It's important to note that the older buses allow easy programmer access to an ISA device, while the new external buses require a layered driver model. The _inp() and _outp() functions give a C/C++ programmer instant access to the ISA device at a given I/O port while USB communications are as follows:
* the operating system or application code issues a command to the device driver,
* the device driver sends commands to the lower driver (e.g., USBD.SYS),
* the lower driver sends commands to the next lower driver (e.g., UHCD.SYS), and
* a frame of data is sent to the USB device.
Much of the device communication relies on software instead of hardware, which slows throughput time.
The IEEE 1394 bus architecture is a high-speed serial bus which currently reaches speeds up to 400 Mb/sec. Further development should allow it to reach 1.2 Gb/sec. The 1394 bus is meant for high-speed devices, such as audio/video and storage devices. Unlike USB, 1394 provides DMA support.
IEEE 1394 transfers data in the asynchronous and isochronous modes. The asynchronous transports data via a memory-mapped region. A driver sets up a data request for a given address and receives acknowledgment upon completion of the request. IEEE 1394 broadcasts isochronous data every 125 [micro]sec in a method somewhat similar to USB.
These new external buses make life simpler for end users, but more difficult for data acquisition developers. Although external devices are fast for bulk data transfers, they are considerably slower for single-point transactions. There is a longer software path to read/write data to the actual device than to interface directly to the device. Therefore, developers need to address latency and performance issues.
USB shares the PCI bus. Therefore, USB must compete for bandwidth with PCI video cards and other USB devices. For example, moving a window while acquiring data may affect performance.
Windows 98 provides new challenges for data acquisition. The newest driver model, WDM, allows binary compatibility between Windows 98 and Windows NT 5.0. The new external buses allow a simple method of attaching devices to the computer. Users can simply attach devices to their computers at any time, allowing them to concentrate on the reason they purchased data-acquisition devices--to acquire and measure data.
Madden is a staff software engineer at National Instruments, Austin, Texas, responsible for data acquisition technologies, bus architectures, and new technologies.
|Printer friendly Cite/link Email Feedback|
|Publication:||R & D|
|Date:||Jan 1, 1998|
|Previous Article:||Managing microscope ergonomy in the lab.|
|Next Article:||DOE requires careful planning: here are four common mistakes researchers make when using the design of experiments approach.|