RS232
Some notes on Microcontroller RS232 Communications
This article is started as one person's experience with Microcontroller RS232 Serial communications on a PIC16F877A, I hope others will add to this and correct any mistakes I may have made. These notes cover some issues that are not commonly discussed, at least in the sources I have seen, or all in one place.
Contents
What hardware: UART or not?
A UART is a peripheral that can send and receive serial data and signal the processor when a full character has been sent or received. ( there are similar peripherals with similar names, they support asynchronous communications, many PIC's have them or variations, so do many other microcontrollers ) Having a UART means that microcontroller can ignore the data for a period of one character ( or more if the UART has a character buffer). If the microcontroller does not have a UART then the processor must time in each bit, normally checking several times a bit to see if the bit is high or low. This is known a “bit banging” Because timing is so critical it is normally done in assembler with careful counting of each instruction to make sure the timing is correct. High level languages sometimes have built in facilities that can manage bit-banging. Changing the timing is non-trivial. Doing much else during the communications process is also difficult. A UART can send and receive at the same time, not so simple with bit banging. In my russ_hensel 's opinion, the UART is so inexpensive that it is not worth the trouble for a hobbyist to do with out the UART.
What language?
Again, in my russ_hensel 's opinion, assembler is just too tedious for the non-professional or non-hard-core. I like C, but other high level languages are good too. Some have libraries or built in functions that handle all the low level details for you. Some will do it in what is essentially bit-banging, still hiding the details.
What handshaking?
One of the traditional problems with RS232 is dropping of bytes. This happens when the sender is too fast for the receiver. How you manage this is called handshaking. There are various methods: Just take it slow and hope it is slow enough – this may work, do some calculations. Works best if a small number of bytes are exchanged only occasionally. This is often the case. Use extra wires to signal when ready ( hardware handshaking ). Too complicated for me. Use “X on X off” protocol ( software handshaking ). Too complicated for me. Send data to the microcontroller as a short enough “command” so that the PIC can buffer the whole thing, then wait for the microcontroller to respond with a signal ( I use a single character “!” ) to indicate that it is ready. Microcontroller responds with responses that are short enough so that the PC can manage them ( and it can manage a lot normally, I believe it has fairly fancy hardware/software to buffer a lot of characters ) or at a data rate that is fairly low. This is the method that I russ_hensel normally use, it is pretty simple and has been pretty reliable for me.
Interrupt driven?
You can make your communications interrupt driven either by letting the UART generate interrupts, or by using a timer to generate interrupts where you poll the UART. Normally this is most useful on the receive end where if you are too slow you loose data. On the transmit end the worst that normally happens is that you send to slowly. How do you decide if the receive should be interrupt driven? This really depends upon your program. What is the most time critical part of the program? Normally I would give that part of the program the use of the interrupt. An example: I was writing a RC servo program and wanted to time a 1 to 2 ms pulse to an accuracy of a few micro-seconds. So I timed the pulses using one of the timers, this gave me an accuracy of about 1 micro-second. In the main loop I would check the UART reception each time around the loop. I know I am ok if the time around the loop plus the time for interrupts that may have happened is less than the time to receive a character. All this is fairly easy to calculate, and it is not too hard to make it around the loop in one character time. At 9600 baud you have about 1 ms per character. You can also check more than once in the main loop. If you need more time, you may want to lower your baud rate. Normally I have found that the character receiving is not the critical task so I have not used the interrupts for communications. Your mileage may vary.
What speed?
Faster is better, but only if it works. Check the manual for your chip to see how close you can get to the exact baud rate with the crystal you have chosen. Try to stay within a few percent. You may want to change your crystal to get a better match. I have used 19.2 K with 4 and 20 meg Hz crystals with good results, I have not tried much with other speeds, could we get reports from other people. If you run too fast for your receive software you may want to drop the baud rate to make reception easier on the microcontroller, also low rates are generally more reliable, how fast do you need to go?: Another issue is the length of the wire you use. You can probably Google to find advice on the longest wire for each baud rate, but in general use lower speeds for longer wires. If you want to go a real long way consider using RS4?? voltage levels ( you will need a converter on the PC as well as the PIC ) to go the distance.
How many wires?
RS232 can run on as few 3 wires, transmit, receive and ground ( maybe even 2 if receive and transmit are shared on one wire ) Other wires may be used for additional functions. I have always used just three and think that this is most common. Three wires is what I recommend.
What voltages?
If you take the signals directly from the PIC the voltages will be the same as the PIC 0 to 5 volts typically, even lower if the supply to the PIC is less than 5 volts. These voltages are too close to 0 to be “standard” for RS232 although I have heard it said that the PC will work with them. Normally people will use a conversion circuit ( an IC that does this is the MAX232, there are others ). You can put this in each project or build it into the cable ( cables for with this built in can be purchased or you can build them ). The cable approach makes the circuit simpler and you can reuse the cable between projects.
Links:
Your Comments:
Edit the text Use the discussion page Contact russ_hensel
