FIFOs were designed to compensate for software and OS latency, in order to help prevent loss of data. For example, when streaming data to a hard drive, the FIFO helps keep sequential data contiguous while the application writes it to disk.

However, during FIFO use, a race is on between the data intake and data output read by the device driver. Ideally, the Data-out speed should be faster than the Data-in speed, in order to avoid a buffer overflow condition. If the FIFO fills up faster than the driver can retrieve its output, a buffer overrun (or overflow) error occurs. Incoming data has no place to be stored and is lost.

Enter DMA
Back to top

Direct Memory Access (DMA) is a means of performing I/O without involving the computer's CPU in the transaction. Bypassing the CPU permits direct data transfer from the data acquisition device to memory; it's a way of speeding up throughput.

During a DMA transfer, the CPU can be used for other tasks without affecting the speed of the data transfer. Typically, a complete set of data is acquired by initiating multiple DMA transactions of 64 kbytes. At the end of each DMA transaction, an ISR is generated and is handled by the device driver.

Multiple DMA transactions can also be chained (that's called chained DMA), making the process even more efficient by reducing the number of ISRs.

There are two styles of DMA design. Bus Master DMA is used with the PCI bus. System DMA is used with the ISA bus.

With Bus Master DMA, all the control circuitry necessary to initiate a DMA transfer exists on the PCI board. With System DMA, the support circuitry is on the motherboard, shared among all ISA peripherals. Bus Master DMA is much more efficient, and the PCI bus operates at a much higher data transfer rate than the older ISA bus.

In either case, DMA requires critical coordination between hardware and software. The hardware must have the proper circuitry, and the software must implement the proper procedures for successful DMA operation.

Polled Vs. Event-Driven
Back to top

Compare polled and event-driven communication control hardware/software methods. In polling, the computer checks many devices to see if they're ready to send or receive data. In the context of a data acquisition system, this typically involves reading or writing a single value from, or to, a data-I/O channel.

In a PC with a Windows OS, the time between polled readings is scheduled by Windows. Therefore, it's nondeterministic. Its operation depends on multiple factors in the system, such as computer speed, OSs, programming languages, and code optimization.

By way of comparison, a deterministic data acquisition system is one that collects data having discrete values, and direct cause-and-effect relationships with the physical phenomena they represent. This implies a strong time relationship between the data and the underlying phenomena.

Data acquisition running in the background using DMA and ISR-driven operations typically is under the control of data acquisition hardware, which notifies the user's application when the task is complete. The time between background readings is clocked by the data acquisition hardware and is independent of Windows timing.

During a background data transfer, the data acquisition hardware interrupts the CPU. The driver handles these interrupts by transferring data into the application memory space. When the requested background operation is finished, the driver posts a Windows message or event to the application, which responds to the event and manipulates the data. (Events and messaging are the processes Windows uses to distribute information to applications and processes within an application, thereby managing its multitasking system). Event-driven programs result in a more deterministic system.

An application that uses polling is simple to program. It's appropriate with slower operations, such as programming discrete steps in a power supply's output, or reading precise voltages from a nanovoltmeter.

Trying to squeeze speed out of a polled application will probably lead to frustration. In applications that use high-speed data acquisition boards for faster sampling rates, event-driven programming is advised. Event-driven programming schemes are less dependent on OS timing, and they reduce latency problems.

Tight Control
Back to top

A programmer can take advantage of Windows events and messaging by using Visual C/C++ and Visual BASIC programming tools to create a deterministic application that runs fast and provides tight control. Instead of constantly status-polling to determine if data are ready for collection, such programs can use the CPU for additional tasks--such as database or network access--until interrupted by the data acquisition hardware.

This tight coordination between data availability and CPU execution also makes event-driven applications more robust and portable across computers of vastly different CPU speeds.

Hardware for Realtime
Back to top

The hardware deployed for realtime applications in Windows is important. Event-driven programming may be necessary, but not necessarily sufficient for some realtime applications. Contrary to what the words imply, realtime tends to be relative, varying with the application and user requirements.

In some applications, users consider a 100-millisecond response as falling within the realm of realtime; in another settings, a one microsecond response time might be needed. Windows, whether it's Win95, 98, NT, or 2000 isn't well suited for fast realtime applications because it doesn't have deterministic timing.

Realtime applications tend to work better with dedicated OSs running on embedded processors. This implies instrument or data acquisition hardware equipped with a digital signal processor (DSP) or microprocessor. The DSP or on-board processor performs many of the functions that would otherwise be performed by the computer's CPU.

The dedicated DSP or CPU approach eliminates problems associated with Windows running tasks in the background that aren't under a user's control. Such tasks use up CPU clocks and interrupt requests, so the test application must share these system resources. Some applications will actually perform better when programmed and run on a DOS system, particularly if the hardware and software were designed around that OS in the first place.

The design of every OS (Windows, DOS, Linux, etc.) attempts to balance several conflicting demands, but tends to be optimized for certain types of tasks. A test-system developer must weigh these tradeoffs. Your ultimate selection will involve compromises between flexibility, functionality, ease of use, robustness, and reliability.

Managing Speed And Accuracy Tradeoffs
Back to top

Since throughput is an issue in most production test applications, a developer must look for programming techniques that speed up processing while maintaining accuracy. In particular, the programmer should avoid a common error: when the PC is much faster than the instruments attached to it, that may lead to poor test results.

This problem arises because the application software outpaces the hardware. Sometimes the hardware driver package will take care of these timing issues; in other cases you must make adjustments in your application program. Here's an example.

In a typical production calibration system, the application program commands the calibrator to apply a certain voltage stimulus to the device under test (DUT) before measuring its response. Both the calibrator and DUT need a certain amount of time, often seconds, to settle to the required state (stimulus or response) before the program commands a measurement. If that amount of time isn't accounted for in the program, the calibration process will be inaccurate.

Typically, programmers hardcode wait times, so this isn't an issue. However, in production tests where throughput is critical, there's a downside: the wait time may be longer than actually needed.

Instead of hardcoding a specific wait time, the programmer can create an algorithm that uses feedback from a calibrator (an instrument-ready bit), to acknowledge that the stimulus voltage level has been reached. This means the program can proceed to the DUT response measurement. The measuring instrument can provide a similar signal after it has acquired the data following a delay, based on its own internal program. This kind of programming approach results in higher production rates.

About the Author
Back to top

Mike Bayda is a Data Acquisition Marketing Engineer with Keithley Instruments. Bayda holds an MSEE degree from Cleveland State University and a BS in Physics from the University of Orleans, France. In the past, he worked as a test engineer at NASA's Lewis Research Center, and now has ten years of experience in test-and-measurement under his belt. E-mail: bayda_mike@keithley.com. Phone: (440) 542-8026.

		Click here to get your listing up.