Instruction manual

AMPDIO DRIVERS
Page 41
TCenableUserInterrupt Like TCenableInterruptChip except that the user interrupt
trigger source is determined from a handle returned by one
of the user interrupt set-up functions.
TCdisableUserInterrupt Like TCdisableInterruptChip except that the user interrupt
trigger source is determined from a handle returned by one
of the user interrupt set-up functions.
The user can ask the driver to read from or write to some of the card’s I/O locations, read timer
values, read an ADC channel, or write to DAC channels when that interrupt occurs and then call
the user-supplied callback function when the required amount of data has been read or more data
is required to be written.
The DIO_TC.DLL supports two different flavours of user interrupt callbacks. The simpler, non-
buffered basic version supports reading a single data value (which may be various combinations of
PPI port values, one or two timer values or a single ADC channel) on each interrupt and calling the
callback function each time. For example, in the meter example, the driver reads the ADC channel
and then calls the user function, which converts the value and displays it as a voltage.
The more general buffered version of user interrupt callback supported by DIO_TC.DLL allows
data to be read from ports, timers or ADC channels into a buffer, or written out to ports or DAC
channels from a buffer and calls the user interrupt callback function whenever enough data has
been read over a number of interrupts to fill the buffer, or more data is required to be written over a
number of interrupts. This flavour of user interrupt callback can be used in single-buffer mode, or
double buffer mode. In double buffer mode, the user callback function can be handling one buffer
whilst the driver is emptying or filling the other buffer, and the driver attempts to maintain the flow of
data whilst buffers are being switched. The double buffer mode is also known as continuous mode.
The mechanism for user call back when reading data from the card on interrupt is:
1. Interrupt occurs.
2. Driver reads interrupt source register.
3. Driver reads appropriate I/O registers and fills in user data.
4. If necessary, the driver signals DIO_TC.DLL, which schedules the appropriate user-supplied
function to be called.
5. Driver acknowledges interrupt and re-enables other system interrupts.
6. If scheduled, the user callback function is called by DIO_TC.DLL.
When writing data to the card on interrupt, the process is similar, but the user callback function is
called to get data to be written before allowing an interrupt to occur.
You can either:
 have a number of different call back routines associated with each interrupt source
(recommended)
or:
 have a generic callback routine and pass a constant in the wParam that identifies which
interrupt source caused the interrupt.
Note that the user call back function executes sometime after the interrupt has occurred. This time
delay is typically 20 s but may be as long as 200 ms if the system is busy writing to disk, network
or printer. This is because the call back is scheduled through the operating system and other
drivers will take priority.
The actual interrupt service latency is variable from machine to machine, but is typically 20 s. The
data read during the interrupt service is read with this latency and not be subject to the delay