CompuScope SDK Manua.. - Egmont Instruments

}
offset += transfer_depth;
position += transfer_depth;
Note: At the end of this routine buffer will hold all the data. The 4 Kilosample transfer size limitation only
applies for the gage_trigger_view_transfer routine using ISA bus CompuScopes.
For PCI CompuScopes that support PCI busmastering, the gage_transfer_buffer_2 and
gage_trigger_view_transfer_2 routines execute a PCI bus-mastering data transfer from on-board
CompuScope memory to host memory (PC RAM). In bus-mastering mode, data are transferred directly
from CompuScope memory to host memory with no CPU mediation required. PCI bus-mastering is the
fastest available PCI data transfer method and can achieve sustained data transfer rates of 100
MegaBytes/second.
The difference between the gage_transfer_buffer_2 and gage_trigger_view_transfer_2 routines is
exactly the same as the difference between gage_transfer_buffer and gage_trigger_view_transfer. That
is, gage_transfer_buffer accepts absolute CompuScope on-board memory addresses, while
gage_trigger_view_transfer downloads data starting at the address specified by the trigger_view_offset
global driver variable.
Internally using PCI bus-mastering, PCI, PCI CompuScope hardware can only transfer data from a d-word
(4 byte) boundary in CompuScope on-board memory. For instance, data can be downloaded starting from
hexadecimal addresses 0x3000 or 3004, but not starting from hexadecimal addresses 0x3001. Because the
gage_transfer_buffer and gage_trigger_view_transfer routines use CPU mediated data transfer, these
details are handled by the drivers and the user need be concerned with data alignment issues. Since
gage_transfer_buffer_2 and gage_trigger_view_transfer_2 do PCI bus-mastering with no CPU
mediation, however, the user must deal with these data alignment issues.
Both gage_transfer_buffer_2 and gage_trigger_view_transfer_2 return a pointer that gives the byte
address location in host memory of the start of the data requested by the call. For instance, let us assume
that the user requested transfer of data starting from CompuScope on-board memory address hex 0x3002.
Let us suppose also that the user allocated a buffer whose starting address is hex 0x10000. Due to its
hardware architecture, the CompuScope would be forced to download data from hexadecimal addresses
0x3000. gage_transfer_buffer_2 and gage_trigger_view_transfer_2 would then return a pointer with
the value of 0x3002 – 0x3000 + 0x10000= 0x10002. So the user application should start looking at the
data starting at pointer value 0x10002 and not at 0x10000.
Because the CompuScope is forced to download data from a d-word boundary, the drivers may need to
download more data than is requested by the users. Consequently, the target host memory buffer must be
slightly larger than the requested amount of data to be transferred. The required amount of padding is
different for different CompuScope models. The best padding method is to use the variable
user_buffer_padding, which is returned by the drivers and is the amount of target buffer padding in Bytes
required for the current CompuScope model. Simply add user_buffer_padding to the amount of memory
to be allocated for the target host memory buffer.
gage_transfer_buffer_3 and gage_trigger_view_transfer_3 are two routines that are similar to
gage_transfer_buffer_2 and gage_trigger_view_transfer_2 routines, except for two very important
differences:
1. Both gage_transfer_buffer_2 and gage_trigger_view_transfer_2 return a pointer that gives the
byte address location in host memory of the start of the data requested by the call. By contrast,
the return value of gage_transfer_buffer_3 is an offset in bytes that specifies the location within
the user allocated buffer to the start of the requested data. For gage_trigger_view_transfer_3,
the return value is an offset in Bytes that specifies the location within the user allocated buffer to
CompuScope API Reference Manual
95