The MgslTransmit call sends one HDLC frame or a data block in other modes to the remote station. Only one MgslTransmit call can be pending at a time. Calling MgslTransmit when a transmit is already pending returns a value of ERROR_BUSY. The application handles transmit queuing and buffering. After calling MgslTransmit, the application should monitor the event object until it becomes signaled, indicating completion. When a transmit call completes, the API sets the transmit status value and signals the event object.
Terminate a pending transmit with the MgslCancelTransmit call. This sends an abort sequence in HDLC mode, and discard remaining transmit data in other modes. The API sets the transmit status to TxStatus_Cancel and signals the event object. Calling MgslCancelTransmit when no transmit is pending has no effect. A transmission may complete normally just after calling MgslCancelTransmit but before actually canceling the transmission.
Calling MgslTransmit automatically enables the transmitter. The transmitter remains enabled after the transmit completes, sending the configured idle character. Calling MgslEnableTransmitter with the enable flag set to FALSE disables an active transmitter, and has no effect on a disabled transmitter. Calling MgslEnableTransmitter with the enable flag set to TRUE enables a disabled transmitter, and has no effect on an enabled transmitter. An active transmitter sends the configured idle character when not sending data. Calling MgslEnableTransmitter with the enable flag set to FALSE will force the immediate cancellation of any pending call to MgslTransmit.
Setting HDLC_FLAG_AUTO_CTS in the Flags field of the MGSL_PARAMS structure causes the adapter to wait until CTS becomes active before sending data. If CTS becomes inactive during a transmission, then the transmission stops immediately and the pending MgslTransmit call completes with TxStatus_CtsFailure. Disabling the HDLC_FLAG_AUTO_CTS option causes the transmitter to operate independently of the CTS signal.
Enabling the HDLC_FLAG_AUTO_RTS option in the MGSL_PARAMS structure causes the API to perform the following actions when data is sent with MgslTransmit.
If RTS is already active because the application asserted RTS with MgslSetSerialSignals, then the driver does not manipulate RTS.
If RTS is not active, the driver asserts RTS before sending the data passed in the MgslTransmit call.
After sending the last bit of the closing flag (HDLC) or last asynchronous byte, the API negates RTS if RTS was asserted by the API in step 2.
This behavior allows the application to keep RTS asserted for multiple chained frames by asserting RTS before calling MgslTransmit for the first frame and negating RTS after the transmit call completes for the last frame. For non-chained frames, the application leaves RTS inactive when calling MgslTransmit, and allows the API to assert and negate RTS for each individual frame. If the HDLC_FLAG_AUTO_RTS flag is not set then RTS is never manipulated by the API. In this case the application must control RTS using MgslSetSerialSignals.
Some DCE devices require RTS to remain active for a period after the last bit of a transmission is sent. Such devices may need this period to allow the data to propagate through the device from the serial port to the physical media. If an application requires that RTS remain asserted for a period after completion of each transmission then auto RTS handling should not be used. The auto RTS handling always negates RTS immediately after sending the last bit of the transmission.
| Previous | Contents | Next |