The trap in performing half duplex communication under windows is that you do not have direct access to the UART chip Line Status Register (LSR) which contains the data ready and tranmitter empty bits. On the transmit side you can not easily check that the bytes you have written to the serial output queue have actually been sent by the UART which has it's own internal "fifo" buffer. On the receive side, you can be receiving data at the UART but not yet have triggered a receive event at the software api level.
The windows api (and the cvi rs232 library that uses it) do not provide a complete set of functions for direct control over the UART chip itself. The Visa api seems to have the same limitation.
If your application is time critical this is a big handycap. Time critical is very relative, microseconds, milliseconds, hundreds of milliseconds. Faster processors have less trouble than slow ones.
For the reasons above there are a number of 3rd party communication libraries that install a replacement serial interface driver with a much more feature rich api. There are also dedicated RS485 cards, like the national cards, that handle half duplex flow control in hardware and avoid the need for an add on library. Windows latency, while a factor, is normally in the microsecond range on current processors when using multiple threads. Depending on your com bus turn around requirements, latency should not be a major factor.
If what your doing is not extremly time critical and you want to try to do this through the CVI rs232 interface it is not very difficult.
You will want to set up your own callback function to handle all rs232 events in a separate thread. Pay particular attention to the fact that when you get a LWRS_RECEIVE event there may be multiple bytes available, or under some circumstances none, see the function help for InstallComCallback()
You can monitor CTS and DSR through GetComLineStatus(). You can also trigger your callback function when the status of these lines change.
Access to set/clear the DTR and RTS lines is available through ComSetEscape().
Use a CVI Thread Safe Queue to pass data between your main application and the 232 callback. Use Thread Safe Variables to setup the flags to indicate when data is ready or needs to be transmitted. When you transmit, setup an timeout period after the last byte has left the transmit queue based on the size of the uart fifo and baud rate. When the timeout expires you can set the bus for receive mode. The time the uart takes to output the data in the transmit fifo after the windows transmit queue goes empty is predictable based on the baud rate to within a few milliseconds.
Good Luck
Message Edited by mvr on 10-09-2005 11:04 AM
