Communication Data Loss
Data loss means unanticipated loss of data or information. A number of techniques are available in communication systems to ensure that receiver sees all of the transmitted data and that data arrives without errors. Following are the major ways to ensure an error free transmission:
- Flow control
- Use of polling or interrupts to detect received data
- Acknowledging received data
- Error checking
Flow control is sometimes called handshaking. Under this technique, a transmitting computer can indicate when it has data to send, and a receiving computer can indicate when it’s ready to receive data. The computers in a serial link should use flow control unless receive buffers are large enough to hold all of the data that might arrive before the receiving computer can read the data from the buffer. In a common form of hardware flow control, the receiver sets a dedicated line to a defined state when ready to receive data. The transmitting computer checks the state of the line before sending data. If the line isn’t in the expected state, the transmitting computer waits. Flow control in both directions requires a line for each direction. However, a full handshake requires 2-way communication: the transmitting computer indicates that it has data to send, and the receiving computer indicates when it is ready to receive the data.
The RS-232 specification assigns names to flow-control signals. On a PC, the input signal is Clear To Send (CTS) and the output signal is Request to Send (RTS). A cable that connects two PCs must connect each RTS output to the other computer’s CTS input. A positive RS-232 voltage means ready to receive and a negative voltage means not ready. Microcontrollers typically don’t have dedicated CTS and RTS lines. Device firmware can use any spare port pins for flow control.
Source code can use names such as flow_control_in and flow_control_out (instead of names RTS and CTS ) to eliminate confusion about which signal is the input and which is the output. Two additional RS-232 flow-control signals are Data Terminal Ready (DTR) and Data Set Ready (DSR). These lines were defined as a means for providing information about the status of a phone line or other communication channel on a modem that connects via RS-232 to a computer or terminal. On PCs, DTR is an output and DSR is an input. Microcontrollers typically don’t have dedicated DTR and DSR lines. Spare port pins with firmware support can provide these signals when needed.
Some links can use software flow control, where a receiving computer sends a Xon code to indicate that the computer is ready to receive and sends an Xoff code to tell the transmitter to stop sending. This method works only when sending data such as plain English text or another encoding that doesn’t use the Xon and Xoff codes in other data.
A link can use hardware and software flow-control methods at the same time. The transmitting computer sends data only if the remote computer’s CTS line is high and the transmitting computer hasn’t received a Xoff.
There are two types of Buffers: Hardware as well as software. Both can help to prevent missed data and enable data to transfer as quickly as possible. The buffers can store received data and data waiting to be sent.
On a port without flow control, a receive buffer can prevent missed data by storing received data until program code can retrieve the data.
On a port with flow control and a receive buffer, the transmitting computer can send large quantities of data even if the receiving computer can’t process the data right away.
Transmit buffers can enable software to store data to be sent and move on to other tasks. Serial ports on PCs typically have 16-byte hardware buffers built into the UARTs.
In the receive direction, the UART can store up to 16 bytes before software needs to read them.
In the transmit direction, the UART can store up to 16 bytes and transmits the bytes using the selected protocol.
Buffers in microcontrollers tend to be small. Some UARTs have no hardware buffers at all. A computer with small or non-existent buffers may need to use other methods to prevent lost data.
Event – driven Programming and Polling
Events that can occur at a serial port include
- Sending and receiving data,
- Changes in flow-control signals
- Errors in received data
- Timeouts when attempting to send or receive data
There are two ways for program code to detect these events.
One way is to jump to a routine when an event occurs. The code responds quickly to port activity without having to waste time checking only to learn that no activity has occurred. This type of programming is called event driven because an external event can break in at any time and cause the program’s execution to branch to a routine to handle the event.
The other approach to detecting events is to poll the port by periodically reading properties, signal states, or registers to find out if an event has occurred. This type of programming doesn’t use a port’s hardware interrupts. The code has to poll often enough to detect all data and events in time to prevent lost data or other problems. The desired frequency of polling depends on buffer size, the amount of data expected, and whether the code must respond quickly to events.
For example, a device that has a 16-byte buffer and polls the port once per second can receive no more than 16 bytes per second or the buffer might overflow and data will be lost. Polling is often appropriate when transferring short bursts of data or when a computer sends a command and expects an immediate reply. A polled interface doesn’t require a hardware interrupt, so you can use this type of programming on a port that doesn’t support hardware interrupts. The code can perform the polling in a task loop that repeatedly performs required tasks, or a timer interrupt can schedule tasks at intervals.
In some applications, the transmitting computer needs an acknowledgment that the data was received. Acknowledgments are especially useful in networks where multiple computers share a communications path and a driver’s switching on at the wrong time can block another computer’s transmission. An acknowledgment can be a defined value, or the transmitting computer can assume that a computer received its message on receiving a response with requested data or other information. A transmitting computer that doesn’t receive an expected response can assume there is a problem and retry or take other action.
When sending to a computer that has no input buffer or a very small buffer, a transmitting computer can use a full handshake to ensure that the receiving computer is ready to receive a block of data. The transmitting computer can begin by sending a code, repeatedly if needed, to announce that the computer wants to send data. On detecting the code, the receiving computer can send a code to acknowledge and then devote full attention to monitoring the serial input. On seeing the acknowledgment, the transmitting computer knows it’s OK to send the rest of the data.
A receiver can use error checking to verify that all data arrived correctly. Ways to check a message for errors include
- Parity bits: A parity bit in each transmitted word enables the receiving computer to detect most errors introduced between the transmitter and receiver. When using .NET’s SerialPort class or other serial-port classes or libraries for PC applications, the application only needs to select a parity type. The software automatically calculates and places the correct parity bit in each transmitted word and can raise an error on receiving data with incorrect parity. Microcontroller hardware and software may require the firmware to calculate and set or check the parity bit for each transmitted and received word.
- Checksums: A checksum is an error-checking value obtained by performing mathematical or logical operations on the contents of a block of data. Hash values are very secure checksums produced by message detection code (MDC) hash functions. To use hash values, the sender and receiver must share a key, which is a value used in creating the hash value and in verifying the received data.
- Sending duplicate data: This is another form of error checking in which the transmitter sends each message twice and the receiver verifies that the message is the same both times. Of course this means each message takes twice as long to transmit. Sending duplicate data can be useful when sending occasional, short bursts of data in an environment prone to errors. Many infrared data links use this method.