INTERRUPTS:

The board driver will usually need to be told which IRQ line to use via an I:n parameter in the DQA.CFG configuration file.

For a board that doesn't have a pacer timer that can signal when each sample is ready, a slightly different method is to have a main system timer generate the interrupt signal at the required sample rate. The interrupt handler does everything as before, but in addition it must explicitly start each sample conversion, and wait until it is done to read the data. For a nominal 100 kHz board which takes 10 µsec for a conversion, we would thus need to wait those 10 µsec in addition to the interrupt overhead. Only a fast machine with low overhead could approach the board's rated 100 kHz sample rate.

A trick can be used with this type of board to restore some performance on slower systems: By using a staggered operation, each interrupt reads data from a conversion started at the end of the previous interrupt. Now the time formerly spent waiting for the conversion to finish is rolled into the time between interrupts. The data is not really from the instant in time that we "thought it was", but once the process is begun it doesn't matter.

Although interrupts are the slowest method to move data, they can still be the best or only choice when greater flexibility is needed. That's because once an interrupt handler becomes active, it can do anything at all... not just acquire data. This allows boards to acquire data and generate stimulus outputs simultaneously, without having special dedicated hardware like dual DMA access or on-board output buffers. Since the vast majority of laboratory-type boards that have DMA don't have this fancier stuff, they may still need interrupt-driven operation for stimulus generation.

DMA:

Boards that support DMA will usually give the best RTime results on machines with 386 processors or higher, and on old XTs (8088 processors). Many machines with 286 processors (and maybe some early 386's as well) suffer from a design quirk wherein the DMA channel runs at HALF the CPU speed... in fact, a PC or XT at 4.77 MHz has better DMA performance than a 286 AT at 6 MHz, since the AT is really a 3 MHz machine as far as DMA is concerned. In these machines a "deep FIFO" board is best.

Your computer supports several different DMA channels or "levels". The board driver will usually need to be told which DMA level to use via an D:n or H:n parameter in the DQA.CFG configuration file.

Some boards running in DMA mode insist upon generating an interrupt after a selectable number of samples, even when it is not required by Daqarta. You will thus need to designate an IRQ number using the I:n parameter, even though the board is using DMA transfers for acquisition. Daqarta typically sets this number of samples as high as possible (65536 for 8-bit data or 32768 for 12- or 16-bit data), so there is little time lost processing the do-nothing interrupt.

All normal ISA-bus sound cards use DMA mode, and many also have dual DMA support for simultaneous data acquisition and STIM3A stimulus generation (full duplex operation).

FIFO:

The FIFO system shares features with both DMA and interrupt systems. It's as though the board has its own little DMA system continuously filling the FIFO instead of system memory. The program transfers data from FIFO to system memory in interrupt-driven bursts of many samples, instead of one at a time as in interrupt-only systems. In this way the interrupt overhead is spread among many samples, reducing the average overhead and allowing faster operation than one interrupt per sample. On those 286 machines with slow DMA, this can even be faster than DMA, especially since block transfers can be used which are faster than single-sample transfers. However, this is only effective if the FIFO pipe is long ("deep") enough to bring the average overhead down substantially... not true on every board that claims FIFO operation.

RTime vs SEQUENTIAL DISPLAY UPDATES:

RTime mode will have this same low update rate at low sample rates only in Triggered operation. In Free-run, however, there will just be a LOT of overlap, and the update rate will still be blazingly fast. RTime is thus definitely the way to run in FFT modes at slow sample rates.

At very high sample rates, the tables may turn. As sample rates go up, the ongoing RTime acquisition steals more frequent time slices from the update process. Eventually the screen updates become noticeably slow, as the GAP values soar... you may be sampling enough data points for hundreds of sweeps per second, but that very sampling is preventing you from getting more than a few!

This is normally only a problem if your board is using interrupt-driven sampling, since the time slices are bigger than for DMA, and more frequent than for FIFO. Stimulus generation on these boards compounds the problem because it must also transfer output samples from memory to the board, adding still more to the length of each slice.

So at high sample rates, Sequential mode may be better. However, if your experiment requires continuous background stimulus generation (an ongoing tone, for instance, instead of one tone burst per sweep), then you are stuck with RTime mode.

RTime vs SEQUENTIAL KEYBOARD RESPONSE:

In RTime mode, high sample rates that cause the overall screen update rate to slow down will cause the keyboard response to lag as well, since no action is taken on the key until the current trace is updated. Daqarta only stores one key request at a time, so at high RTime sample rates you may need to type slowly so that each key can be recognized before it is overwritten by the next.

• Back to Interrupts.
• Back to Real-Time / Sequential contents.
• Daqarta for DOS Help contents.
• Daqarta for DOS Index.
• Daqarta home page.
• Daqarta download options.
• Free Registration

Questions? Comments? Contact us!