Raw, Bisync, Monosync Modes

Raw, bisync, and monosync modes are closely related protocols. These modes do not have hardware framing, hardware transparency, and hardware CRC generation and checking. Interpretation of data, definition of block boundaries, and error checking are all performed by the application.

Receiving Data

Raw mode has no hardware synchronization. When the receiver is enabled, it immediately starts returning data without regard to any byte boundaires. The application is responsible for any necessary data alignment. The receiver continues to return data until disabled.

Bisync uses 16-bit hardware synchronization and monosync uses 8-bit hardware synchronization. When enabled. the receiver will not return data until the synchronization pattern is detected. All data is aligned to the synchronization patterns. Data continues to be received until the receiver is disabled or forced into hunt (idle) mode by the application.

Raw, bisync, and monosync modes may optionally use the Data Carrier Detect (DCD) input signal as a hardware receiver enable. This is done by setting HDLC_FLAG_AUTO_DCD in the Flags field of the MGSL_PARAMS structure.

Each call to MgslReceive() completes when the buffer has been completely filled to the size specified in the DataLength field of the MGSL_RECEIVE_REQUEST structure. If the receiver is disabled by the application or by DCD going inactive, any remaining receive data in the API buffers is returned and MgslReceive may complete with the buffer only partially filled.

Sending Data

Raw, bisync, and monosync modes have three transmitter states: disabled, idle, active. When disabled, the transmit data signal is a constant mark. When idle (not sending data, but enabled), the transmitter sends the idle (raw) or sync (bisync/monosync) pattern. When active, the transmitter sends data provided by the application.

Bisync and monosync modes require a synchronization pattern. This pattern must be included at the beginning of a block of data sent by the application. Depending on the application, the sync pattern may be repeated multiple times before the start of a block. The sync pattern is used by the remote receiver to enable reception and align data to the sync pattern boundaries.

Raw, bisync, and monosync modes allow sending of arbitrarily long blocks of data. Block boundaries are defined by the application. As long as the API has buffered send data, the transmitter sends an uninterrupted stream of bits (raw) or bytes (bisync/monosync). If the API runs out of send data, the idle (raw) or sync (bisync/monosync) patterns are sent.

To maintain a constant stream of send data, the application should use buffered transmissions. This is done by calling MgslTransmit with a status argument of NULL. This causes MgslTransmit to complete when the data has been buffered, but not actually sent. Repeated calls to MgslTransmit with a NULL status argument keeps the buffers full, allowing a constant stream of send data. See the MgslTransmit documentation for more details.

Previous Contents Next