Send a file thru RS232

It depends on what you want from this protocol. If you don't need error detection or stuff like that, you could just send the whole file byte-by-byte in one big chunk of raw binary data.

Just one big chunk of binary file...do I use the Z-modem protocol or is there a better one? Also, how would I set it up in my C-code for the 8051? Is it just the same as reading from RS232 thru hyperterminal?

Are you talking about uC to uC, PC to uC, modem or what ?

Erik

PC to uC...thru RS232

Hi Tommy!

Well, if you want something that is bullet proof or you are transmitting the data via modem, I would suggest z-modem. There is an "industrial z-modem" available at http://www.omen.com . YOu have to pay for it (once, not for eveyr sold item), though. Other than that, I have seen some x-modem source code floating around the web.

If you can live with something propreatary, youc an develop your own protocol... that shouldn't be hard if you only transmit via RS232 cable. Just define a paket format and add an 8 bit CRC. That is easy.

Take care
Sven

Is this the same application as when you posted earlier about Z-Modem?

As I said there, if you're just sending it down a short cable, do you need any protocol at all?
Why not just send the Hex file?
The Intel Hex format has a checksum on each line already - should be fine in this application?

"raw binary data"

be careful that your PC is set up to allow raw binary data - ie, no software flow control, etc!

This is the very reason that Intel Hex format was developed (and other similar schemes like the Motorola S-Records, and UU-Encode)

Hi Andrew!

Yes, I have mentioned the industrial z-modem somewhere before (didn't know it was here).

Intel Hex is sure ok, but in case the data has to be transmitted in a reasonable time, it wouldn't be my choice, since one byte is blown up to be two bytes (plus a little over head). HEX format is cool for sending firmware updates ofcourse, since most linkers produce it. And for quick and dirty solutions it isn't any bad.

"Yes, I have mentioned the industrial z-modem somewhere before"

Sorry, my question was directed to Tommy Kwan!

"HEX format is cool for sending firmware updates"

I get the impression that this is what he's trying to do!
So come on Tommy - spill the beans!

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.

I can send either a raw binary file, raw hex file (separated by comma), or intel format hexadecimal file. The whole point of this project is the file is sent thru RS232 for remote programming of another chip. Speed is not an issue just as long as it is under a few minutes. Most importantly, the data, about 256kbytes, that I recieved will be simultaneously programmed into an EEPROM. I like to say thank you for all the help from all of you!

Depending on how fast the EEPROM can be programmed, and how fast the incoming data is, you will probably need some kind of handshake to allow time for the programming to complete, or to handle error cases. You will also need a buffer large enough on the receiving end to store the data to be programmed.

The incoming data is much slower than the speed I am writing to the EEPROM. Therefore, whenever there is an incoming data, I will write straight to EEPROM.

Tommy, as you say that speed is not a problem, my personal inclination would be to keep things as simple and convenient as possible. Go for Intel format and start with a prototype version that simply ignores all those checksums. Get things working and add the bells and whistles that experience (and common sense) tells you are necessary.

If you really want to keep things simple, consider having a write command and a verify command. In the case of a verify, the file is downloaded again, and the receiver simply checks that the data is identical to that received previously. This will save you from having to worry about checksums, CRCs etc.

If you are actually downloading code that ends up getting executed, the code could include its own CRC check - which is not a bad idea anyway.

you have to determind the datum format,i.e.,what's the meaning of each byte,including shakehand-byte(s) and checking byte(s).