Send a file thru RS232

Tommy, I don't think that anybody can make a specific recommendation without knowing very specific details of the problem. You will have to think about:

What speed of transfer you require (is transmission speed an issue?)
What level of errors your transmission medium is likely to give (bit error rate).
What is the character of transmission errors (random or bursty).
What level of (or probability of) undetected errors in your file can be tolerated?

A burst error is an error in two or more bits in stream of data protected by the same error detection mechanism. The length of the burst error is the longest distance (in bits) between two incorrect bits in the stream of data.

Off-the-shelf protocols are aimed at solving real-world problems of transmitting efficiently (highest possible speed) over an inherently noisy (high bit error rate) medium. Off-the-shelf protocols typically have error detection and correction mechanisms and may also have features for compression and encryption.

But off-the-shelf protocols are not always necessary (or even desirable). If the transmission medium is reliable (low bit error rate) then the error correction may be imposing an unnecessarily high overhead. Or, if the low bit error rate is not required (the data is inherently redundant – eg. a picture).

If the application is undemanding, implementing your own protocol should be straightforward. If speed is not an issue, send each byte as two ASCII hexadecimal characters – debugging is very much easier and the limited character set allows some simple tests on the received data. Use a carriage return or some other character to indicate end-of-file. If the bit error rate is low, a CRC at the end of the file will verify correct reception.

Note. CRCs are very effective at detecting errors. Don't be tempted to use a simple checksum – they are perfidious. Use at least a 16-bit CRC. An 8-bit CRC is not guaranteed to detect a bust error of more than 8 bits and if there is such a burst error, the CRC will fail to detect it 1 time in 256 – usually not good enough.

Note that one big CRC covering the whole file can be better than lots of little CRCs each covering a small portion of the data. The reason is that in the real world errors are not random, but tend to come in short bursts. Therefore, an error busrt tends to affect just one packet and a small CRC has a high chance of failing to detect the error. Many protocols have small CRC to protect individual packets - to allow errors to be corrected as each packet is transfered and have another larger CRC to allow error detection in a whole file.

If you choose to transmit binary data, note that CRCs are guaranteed to detect burst errors that are no longer than the number of bits in the CRC. As you are transmitting 8-bit words in an asynchronous frame, one possible source of errors is your UART could get out of synchronisation – perhaps due to a false start bit. But, if you always have two stop bits, the UART must resynchronise in less than 4 8-bit words. In this case, it may be wise to choose a 32-bit CRC – very unlikely to fail to detect an error.

Error correction can be achieved by repeating the transmission of the whole file.

Tommy, I don't think that anybody can make a specific recommendation without knowing very specific details of the problem. You will have to think about:

What speed of transfer you require (is transmission speed an issue?)
What level of errors your transmission medium is likely to give (bit error rate).
What is the character of transmission errors (random or bursty).
What level of (or probability of) undetected errors in your file can be tolerated?

A burst error is an error in two or more bits in stream of data protected by the same error detection mechanism. The length of the burst error is the longest distance (in bits) between two incorrect bits in the stream of data.

Off-the-shelf protocols are aimed at solving real-world problems of transmitting efficiently (highest possible speed) over an inherently noisy (high bit error rate) medium. Off-the-shelf protocols typically have error detection and correction mechanisms and may also have features for compression and encryption.

But off-the-shelf protocols are not always necessary (or even desirable). If the transmission medium is reliable (low bit error rate) then the error correction may be imposing an unnecessarily high overhead. Or, if the low bit error rate is not required (the data is inherently redundant – eg. a picture).

If the application is undemanding, implementing your own protocol should be straightforward. If speed is not an issue, send each byte as two ASCII hexadecimal characters – debugging is very much easier and the limited character set allows some simple tests on the received data. Use a carriage return or some other character to indicate end-of-file. If the bit error rate is low, a CRC at the end of the file will verify correct reception.

Note. CRCs are very effective at detecting errors. Don't be tempted to use a simple checksum – they are perfidious. Use at least a 16-bit CRC. An 8-bit CRC is not guaranteed to detect a bust error of more than 8 bits and if there is such a burst error, the CRC will fail to detect it 1 time in 256 – usually not good enough.

Note that one big CRC covering the whole file can be better than lots of little CRCs each covering a small portion of the data. The reason is that in the real world errors are not random, but tend to come in short bursts. Therefore, an error busrt tends to affect just one packet and a small CRC has a high chance of failing to detect the error. Many protocols have small CRC to protect individual packets - to allow errors to be corrected as each packet is transfered and have another larger CRC to allow error detection in a whole file.

If you choose to transmit binary data, note that CRCs are guaranteed to detect burst errors that are no longer than the number of bits in the CRC. As you are transmitting 8-bit words in an asynchronous frame, one possible source of errors is your UART could get out of synchronisation – perhaps due to a false start bit. But, if you always have two stop bits, the UART must resynchronise in less than 4 8-bit words. In this case, it may be wise to choose a 32-bit CRC – very unlikely to fail to detect an error.

Error correction can be achieved by repeating the transmission of the whole file.