User manual

Programmer’s Guide Page 30 of 64
(B) More Efficient Polling: use this code fragment to release the polling thread for short periods:
ViBoolean done = 0;
long timeoutCounter = 100;
while ((!done) && (--timeoutCounter > 0))
{
AcqrsD1_acqDone(instrID, &done); // poll for status or
Sleep(1);
}
if (timeoutCounter <= 0) // timeout, stop acquisition
STOP ACQUISITION
This code puts the polling thread to sleep for periods of 1 ms at a time, letting other threads of the application or
other applications use the CPU time. Setting the timeout counter to 100 means that a total timeout period of 100 ms
is expected.
NOTE: This method still has some drawbacks:
• depending on the operating system, the 'Sleep' method often has a granularity of 10 ms or more, rounding any
smaller number up to this minimum value
• the response time of the application to the end of acquisition is 50% of the sleep time, on average. With a
granularity of 10 ms, the mean latency is therefore 5 ms. Thus, no more than 200 waveforms per second could
be acquired, because the application wastes time waiting for the acquisition to terminate.
(C) Waiting for Interrupt:
ViStatus status;
long timeOut = 100; // in ms
status = AcqrsD1_waitForEndOfAcquisition(instrID, timeOut);
if (status == ACQIRIS_ERROR_ACQ_TIMEOUT) // timeout, stop
STOP ACQUISITION
This method combines low CPU usage with very good response time:
The function enables the instrument’s 'end-of-acquisition' interrupt and sets up a semaphore that waits for this
interrupt. It then releases the thread by 'going to sleep', thus letting other threads of the application or other
applications use the CPU time. The function returns as soon as the interrupt occurs or when the timeout expires. Note
that the timeout asked for will be clipped to a maximum value of 10 seconds.
We recommend using AcqrsXX_waitForEndOfAcquisition since it is the most efficient method. The interrupt
latency is of the order of several µs, and no CPU time is wasted.
3.10.4. Stopping/Forcing a D1-style Acquisition
The previous section shows a case where an ongoing acquisition must be stopped, typically because there is no
trigger. Also, in some situations you may want to use the digitizer to generate a system trigger under software
control.
If you still would like to have a valid snapshot of the current input signal, you should generate a trigger signal by
software, with the function AcqrsD1_forceTrig or AcqrsD1_forceTrigEx. Typically, the acquisition does not stop
immediately, since the digitizer may continue acquiring some additional data, depending on the delayTime and the
data acquisition time that were initially configured. Thus, the application should again wait for the acquisition to
terminate. Forcing a trigger does not make sense for averagers and analyzers and should not be done.
AcqrsD1_forceTrigEx allows you to generate a trigger out signal which can be synchronized with the sampling
clock if desired.
Use the following code fragment to replace STOP ACQUISITION in the previous section: