XT2640 Operating Manual
13 July 2016
Page 137 of 187
This function flushes the receive buffer in the XT2640 and the HID driver.
HID_UART_STATUS HidUart_FlushBuffers (HID_UART_DEVICE device, BOOL flushTransmit, BOOL
flushReceive)
device
—Device object pointer as returned by
HidUart_Open()
.
flushTransmit
—Set to
TRUE
to flush the device transmit buffer.
flushReceive
—Set to
TRUE
to flush the device receive buffer and HID receive buffer.
Return Value: HID_UART_STATUS = HID_UART_SUCCESS, HID_UART_INVALID_DEVICE_OBJECT,
HID_UART_DEVICE_IO_FAILED
HidUart_Cancello
This function cancels any pending HID reads and writes.
HID_UART_STATUS HidUart_CancelIo (HID_UART_DEVICE device)
device
—Device object pointer as returned by
HidUart_Open()
.
Return Value: HID_UART_STATUS = HID_UART_SUCCESS, HID_UART_INVALID_DEVICE_OBJECT,
HID_UART_DEVICE_IO_FAILED
HidUart_SetTimeouts
Sets the read and write timeouts. Timeouts are used for
HidUart_Read()
and
HidUart_Write()
. The default value for timeouts
is 1000 ms, but timeouts can be set to wait for any number of milliseconds between 0 and 0xFFFFFFFF.
HID_UART_STATUS HidUart_SetTimeouts (HID_UART_DEVICE device, DWORD readTimeout, DWORD
writeTimeout)
device
—Device object pointer as returned by
HidUart_Open()
.
readTimeout
—
HidUart_Read()
operation timeout in milliseconds.
writeTimeout
—
HidUart_Write()
operation timeout in milliseconds.
Return Value: HID_UART_STATUS = HID_UART_SUCCESS, HID_UART_INVALID_DEVICE_OBJECT
Note ‐ If read timeouts are set to a large value and no data is received, then the application may appear unresponsive. It is
recommended to set timeouts appropriately before using the device.
HidUart_SetUartConfig
Sets the baud rate, data bits, parity, stop bits, and flow control. Caution, this sets parameters within the XT2640 – do NOT
alter these settings from those shown below.
HidUart_SetUartConfig(device, 115200, HID_UART_EIGHT_DATA_BITS, HID_UART_NO_PARITY,
HID_UART_SHORT_STOP_BIT, HID_UART_RTS_CTS_FLOW_CONTROL)
device
—Device object pointer as returned by
HidUart_Open()
.
Return Value: HID_UART_STATUS = HID_UART_SUCCESS, HID_UART_INVALID_PARAMETER,
HID_UART_INVALID_DEVICE_OBJECT, HID_UART_DEVICE_IO_FAILED
24.1.4
GPIB
INTERFACE
The GPIB capabilities, as defined by IEEE488.1 are SH1 AH1 T6 L4 SR1 RL1 PP1 DC1 DT0 C0 E2.
24.1.4.1
CONNECTING
TO
THE
GPIB
INTERFACE
It is recommended to use a high quality, shielded, GPIB cable. Suitable cables are available from XiTRON in a selection of lengths.
24.1.4.2
REMOTE
AND
LOCAL
OPERATION
The GPIB itself has a protocol for establishing and controlling the local/remote state of the XT2640 so there are no XT2640
commands required to do so as for other available interfaces. The front panel button (shown when in the remote state) requests that
the local state be entered, but it is the GPIB interface which actually controls that state and may deny that request.
24.1.4.3
WRITING
SOFTWARE
TO
CONTROL
THE
XT2640
VIA
GPIB
Generally messages and controls are sent and received via the GPIB using calls into the DLL driver provided by the manufacturer of
the specific GPIB controller being used in the computer. You should consult the documentation provided with the controller
regarding writing software to communicate with the XT2640.
24.1.4.3.1
Terminating
Command
Sets
In addition to the command terminator characters described in 24.2.1.1 the use of the EOI signal of the GPIB interface may be used.
24.1.4.3.2
Receiving
Responses
via
the
GPIB
Interface
The XT2640 always terminates all responses with the CR and LF characters as in the other available interfaces, however for the GPIB
interface the EOI interface signal is also asserted with the LF character.
Unlike the other interfaces available for the XT2640, the GPIB requires an action from the controller to be able to receive response
information from the XT2640. This activity could occur in the GPIB interface when no response is available.
Many devices simply hold the GPIB interface when this occurs and rely on a timeout occurring at the controller to release the GPIB.
The XT2640 always provides a response, and that response is always terminated by the CR and LF characters (the later with EOI
asserted). If there is no response then there are no response characters preceding the CR, but the CR and LF+EOI characters are
always transmitted. In this manner the bus itself does not become “hung” when this occurs, but instead you must consider the
possibility of receiving a response which contains nothing in your software.