PIC RS232

From Mech
Revision as of 12:52, 27 December 2007 by LIMS (talk | contribs)
Jump to navigationJump to search
Usb-serial-adapter2.jpg

RS232 serial communication is an ancient, low speed, reliable standard. Each of about 100 characters (a, b, c, 1, 2, 3...) has a one-byte ASCII code. These are transmitted as 8 consecutive low and high logic levels, with a few framing bits as well. Baud rate refers to the number of bits/second. A typical baud rate is 19200, which is about 10000 times slower than USB. The original teletype machines were 110 baud. Read more about RS232 on wikipedia.

All desktop and laptop computers used to have a serial or "COM" port, available through a male DB-9 connector. These are getting less common on newer computers. However you can get an inexpensive "USB to Serial Adapter" which makes a DB-9 COM port available, once you install some driver software.

The 18F4520 PIC has a built-in UART for transmitting and receiving characters on RS232 standard. After you make the hardware connection -- the PIC's transmit pin sends to the PC/laptop's receive pin and vice versa -- you can open a text window on the PC/laptop and see whatever your PIC program prints, and type characters that will be transmitted to your PIC.

A text window on your PC

The CCS IDE has a built-in text window for this purpose, shown at the bottom of this page. You can also use Hyperterminal, which actually works somewhat better. It is a Windows ap usually found at Programs/Accessories/Communications/Hyperterminal


Db9.jpg

Do I need to hook up all 9 pins?

No, you only need three: transmit, receive, and ground. The rest have purposes but are seldom used any more. You do have to get the baud rate and a few other parameters matched, between whatever your two communicating partners are.

On a standard male DB-9 COM connector on a computer, 2=input to computer, 3=output from computer, 5=ground.

The connector you build will be female with the same pin numbers for the same purposes. Photo at right shows the pin numbering on the female DB-9.


Max232n-03.gif


Voltage problems: important!

PC/laptops use +12 volt and -7 volt signals The official RS232 standard uses +12V and -7V for logic 1 and 0 (or maybe the other way around). The PIC can only produce 5V logic levels, and it can be damaged by voltages above 5V. So although the PIC and your PC/laptop agree about the code for transmitting characters, they don't agree about the voltage levels.

Some devices use "5 volt RS232" Quite a lot of devices use 0 and 5V logic levels instead of the higher voltages that the RS232 standard specifies. The PIC does this, and so do Serial 2-line LCD Displays, which are very handy. So these can be connected directly.


Max232n-06.gif


Shifting voltage levels

For interfacing a PIC to a PC/laptop or to a Serial-to-USB Adapter, you need a level converter. The MAX232N is a lovely chip that serves this function, in both directions (PC to PIC and PIC to PC). In fact it has two channels in each direction, should you ever want that many. You would think that in order to produce 12V signals it would need a +12V power supply, and maybe a negative supply as well, but it doesn't, it produces the needed +12V and -7V internally from a single convenient 5V supply.



Using the MAX232N

The chip needs five 1uF capacitors around it, which is not a lot to ask for sparing you two extra supply voltages. Connect MAX232N pins 13 & 14 (and ground) to a female DB-9 connector as shown, and plug into your PC/laptop's serial port. Connect MAX232N pins 11 & 12 to your PIC. If you only want PIC output, you don't need to hook up the PIC input.

  • PIC to PC: PIN pin 25 (RC6/TX) --> MAX232N pin 11 --> MAX232N pin 14 --> DB-9 pin 2
  • PC to PIC: DB-9 pin 3 --> MAX232N pin 13 --> MAX232N pin 12 --> PIC pin 26 (RC7/RX)


Code on the PIC

The essential line is #use rs232(baud=19200, UART1). This sets up the PIC's hardware UART. The PIC can also can do software RS232, but that is susceptible to mistiming caused by interrupts.

Once the UART is set up, you can use most of the usual C serial i/o functions, such as printf(). There's no scanf() in PIC C, and be sure to read about the formatting codes (%d and so on.)

Note - Characters transmitted to the PIC faster than your program reads them cause the UART to choke. After that happens, kbhit() never returns TRUE again, and no characters can be read. So use PIC RS232 input with care. If you want reliable input you have to set up an interrupt on incoming characters.

#include <18f4520.h>
#fuses HS,NOLVP,NOWDT,NOPROTECT        
#use delay(clock=20000000)         // 20 MHz crystal on PCB
#use rs232(baud=19200, UART1)      // hardware UART; uses  RC6/TX and RC7/RX  
 
int16 i;
int j;
 
void main() {
 
   while (TRUE) { 
    
      for (i=1; i<10000; i++) {
         printf("Hello world. %Lu %u\r\n", i, j);  // \r is carriage return, \n is scroll up
         delay_ms(100);
         if (kbhit()) j = getc();     // type slowly so kbhit() doesn't choke
      }
   }
}


Serialconfiguration.gif


Configuring your COM port and the Loopback Test

Shown at right are the usual configuration options for the COM port on your computer. Baud rate must match that of the PIC. There is the problem of which COM port to select, and whether the one you have made electrical connection to (through a DB-9 connector) is that one.

To check your COM port, try the Loopback Test. With the DB-9 disconnected, if you type "hello" into the text window ("serial port monitor") you will not see "hello" appear in the window, because your characters went out on pin 3 of the DB-9. The window shows only characters arriving on pin 2 of the DB-9; there is no Local Echo. If you connect pin 2 to pin 3 temporarily and type again, you will now see your words. Thus you have identified electrical signals that correspond to your COM port and text window.

Typical other problems are:

  • Different baud rates (sometimes resulting is garbled transmission, sometimes no transmission)
  • DB-9 pins 2 & 3 (computer receive and transmit) not going to partner's transmit & receive, respectively
  • You didn't level shift appropriately and now things are burned out.
  • Partner (e.g. PIC) is not transmitting anything. Look with a scope and see if there's anything happening on partner's transmit line.

Textwindow.gif