Synchronization issues for on-the-fly commands

This topic details a subtle difference between the timing of out-of-band and inband on-the-fly commands (relative to the data being sent by the VSP ).

In certain serial systems transmission of data by the PC is synchronized with toggling of RTS or DTR outputs (or with changing of the serial port setup). Consider the following two examples:

Example 1: The RTS line is used to mark the beginning and the end of the data transmission by the PC.

The diagram of such data transmission is shown below. When the PC wants to send out the data it does the following:

The positive pulse on the RTS line is said to envelope or encapsulate the data.

Example 2:mark and space parity bits are used by the serial device to distinguish between the address and data bytes transmitted by the PC.

In most RS485 systems (where there are multiple serial devices attached to the serial bus) the PC needs to select a particular "node" it wants to communicate with by transmitting the address of this node. Such systems often use the parity bit to distinguish between the node address and the actual data, i.e. (parity= mark means an address byte, parity= space means a is data byte, or vise versa).

Since a standard COM driver does not allow the application software to control the parity bit directly, such software uses the following algorithm to transmit the node address followed by the data:

The point here is that changes in the parity mode must be synchronized with the data being sent out.

How the use of VSP affects synchronization ****

The operation of the VSP is more asynchronous than that of a standard serial port. When the application sends out the data the VSP just puts this data into the Tx buffer and returns control back to the application. To the application this means that the data has been sent out. Obviously, this is not so and there will be a certain delay before this serial data actually comes out of the serial port on the DS side.

Out-of-band commands (such as the command that tells the DS to change the state of the RTS line) are sent separately from the data. For example, when the application tells the VSP to change the state of the RTS line the VSP sends a required out-of-band command immediately.

For the example 1 the above means that the pulse on the RTS line will be completely out of sync with the serial data itself (the diagram below illustrates this). For the example 2 this means that the switching of the parity mode will occur at wrong (and unpredictable) times and, therefore, there is no guarantee that the address byte will be output with mark parity bit and the data byte will be output with space parity bit!

The solution

Fortunately, there is a solution to this problem- use inband mode when trying to achieve full synchronization between the Tx data and on-the-fly commands! Because inband on-the-fly commands are mixed into the data stream itself there is no chance that these commands will somehow "pass over" the data. The DS will receive the data and corresponding on-the-fly commands in exactly the same order as generated by the application.