| View previous topic :: View next topic |
| Author |
Message |
JohnKennedy
Joined: 12 May 2004
Posts: 38
|
| Advice for Serial Comms |
 Posted: Wed Dec 21, 2005 5:25 am |
 |
|
Hi
I have an application that I need to start in the new year that requires RS232 communication. I haven't done anything on this using a PIC in the past so I'm looking for some recommended sources of information.
thanks
JFK |
|
 |
yerpa
Joined: 19 Feb 2004
Posts: 58
Location: Wisconsin
|
|
| Posted: Wed Dec 21, 2005 3:12 pm |
|
|
| Life is easier if you use a PIC with a hardware UART built-in, rather than doing a bit-banged port in software. The bit-banged port only makes sense in high volume low cost applications. |
|
|
kender
Joined: 09 Aug 2004
Posts: 768
Location: Silicon Valley
|
|
| Posted: Wed Dec 21, 2005 10:50 pm |
|
|
| Don't forget the RS-232 transceive such as MAX232. Keep in mind also that most of the laptops produced these days have no RS-232 port. |
|
|
jds-pic
Joined: 17 Sep 2003
Posts: 205
|
| Re: Advice for Serial Comms |
| Posted: Thu Dec 22, 2005 3:33 pm |
|
|
| JohnKennedy wrote: | | I have an application that I need to start in the new year that requires RS232 communication. I haven't done anything on this using a PIC in the past so I'm looking for some recommended sources of information. |
i would start by getting any of the various PIC development boards that have 1) a PIC with hardware UART, and 2) an on-board level converter such as noted above like the MAX232.
with this hardware, you can use a simple serial cable to connect to your PC and you can then begin to code up a trivial program for the PIC board to spit out "hello world" to the PC. (note: on the PC, please use anything BUT MS Hyperterminal -- it is not worthy of your time.) the TX part of your work is easy, implementation wise...
once you have "hello world" on your PC screen, you can start back the other way, where you will need to use either polling or interrupts to capture bytes from the PC on the PIC. here you will find the real work of serial communications, namely managing time and buffers while trying to do other tasks. it can be easy or very simple, depending on how much other work needs to be done. if the PIC just sits waiting for a command from the PC ("temperature?"), then runs off an executes some code (get_temperature();), and then reports back to the PC ("send_temperature();), your job will be very straightforward.
on the other hand, if the PIC is generally busy and bytes arrive asynchronously from the PC, you'll need to implement a little state machine to handle interupt-driven receipt of bytes and then act when command parsing is done.
you'll note that a little thinking beforehand *at the system level* before starting implementation can save you a lot of coding and a lot of headaches. for example, it's a good idea to elect one endpoint as the master (typ. the PC) and the other as a slave (typ. the PIC). now you can draw a state diagram for the entire system, which shows who initiates communication and how fault recovery is handled (ooops, someone disconnected the serial cable!).
regards,
jds-pic |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
