I'm looking for resources to help me as i design the PC to Microcontroller serial interface for a robotic application i'm currently building. Does anyone know of any good theoretical books, webpages, ect. that cover computer to Microcontroller comunication. Idealy i'm looking for something a bit theoretical.
Thanks,
Owen
serial comunication
-
owenhooker
- Posts: 4
- Joined: Wed Nov 22, 2006 4:29 am
- Contact:
Owen... Welcome to the forum
If you dont have a Micro preference I will go with my favorite... Texas Instruments MSP430. I like TI for all the information they give to the user...
Heres a project worth checking out... a Bidirectional Wireless UART Application using a TRF6903 and MSP430
http://focus.ti.com/general/docs/techdo ... me=swra039
The above project would be considered an "overkill" to what you want to do... but you can learn a lot from reading the PDF. TI also provides code for you to use.
I would love to see your progress on this project.
If you dont have a Micro preference I will go with my favorite... Texas Instruments MSP430. I like TI for all the information they give to the user...
Heres a project worth checking out... a Bidirectional Wireless UART Application using a TRF6903 and MSP430
http://focus.ti.com/general/docs/techdo ... me=swra039
The above project would be considered an "overkill" to what you want to do... but you can learn a lot from reading the PDF. TI also provides code for you to use.
I would love to see your progress on this project.
Using Serial RS-232 / USB with a Microcontroller
When you say "serial communications" and "theoretical", it doesn't seem to match designing a robotic application.
Theoretical aspects of serial communication go into data communications protocols, NRZ, multi-level signaling and error correction circuitry.
If you just want to build a link, then I'd first ask what kind of data rate you need (what kinds of volumes of data are you sending) and what ports do you have on your PC?
The easiest, by far, is RS-232. USB isn't too difficult if you use chipsets like the FTDI 232RL and use their virtual com-port drivers. The virtual com port drivers must be installed on a PC. Once those are in place, the USB port appears as any other COM port and you may read them on the PC using C programming language, Tcl/Tk, or whatever... but they become just another COM port.
First, I'd start with an understanding of RS-232. While there are many serial interfaces (e.g. SPI) RS232 is a common serial interface also used by PCs. Even if you want to use USB, you will likely use RS-232 on your microcontroller side (with TTL voltage levels, 0-5V) and then use a FTDI 232RL or equivalent to convert to the differential USB signals & protocol. The chip does the work for you-- just send TTL-level RS-232 IN and USB comes out!
A FANTASTIC place to start for RS-232 is the Wiki page. Go to Google and search for "RS232 wiki". The Wiki page should be right there and it will tell you much of what you need to know, including the signal voltage levels, data rates, pinouts of connectors and so forth.
The standard which RS232 uses has FAR more capabilities than is typically required for hobbiests. For example, using a simple DB-9 connector on PCs, you can establish an RS-232 connection with only Ground, TX and RX lines. That's enough to send data. Simply short the two CTS-RTS lines to each other and also short the DSR-DTR lines to each other on your microcontroller application side. That has the effect of proping the communication doors wide open so the PC is always has clearance to send data at any time.
But if you want to send more than an occasional data message and the microcontroller is busy doing other things, then consider adding the "CTS" and "RTS" lines to do hardware "flow control" so each side can say when the other side is "clear to send". That way, if your micrcontroller is busy, it can tell that to the PC, forcing it to wait 'till it's ready. But CTS-RTS flow control is NOT required. You just run the risk of loosing data, but you decide if that risk is big or not. Just Gnd, TX, RX. In fact, if your data flow is one way, you may only need a Gnd-TX or Gnd-RX!!
Sending serial data from a microcontroller to a PC requires a signal-level translation. RS-232 hardware signals ranges from -3 to -15V and +3 to +15 V. Microcontrollers are more like 0-5V or 0-3V. Those don't line up, so you need to use a chip like a "MAX232", by far the most popular for hobbiests. The chip is super easy to use and only requires a couple extra cap components to use.
For implementing this in robotics, I'd HIGHLY recommend the book, "Programming Robot Controllers" by Myke Predko,
http://www.amazon.com/Programming-Robot ... 0071408517
He discusses how to do the real RS-232 hookup (what I've described above) and why you want to short the CTS-RTS lines and short the DSR-DTR lines on your application.
A NOTE: When dealing with anything RS-232, BE CAREUL with the names. "TX" is a transmit line for someone... but who? The transmit on one side must go to a receive on the other side. Someone gets to transmit on the TX line while someone else must receive on the TX line.
To help with this distinction, one side (the PC) is often dubbed the "DTE" (Data terminal equipment-- the PC) and the other side is dubbed the "DCE" (data communication's equipment-- the microcontroller). This is a throwback to the days when terminals communicated with modems via RS-232.
TX (pin 3 on a DB 9 connector) means "transmit line" from the perspective of the DTE (computer/PC). Therefore, your microcontroller (DCE) will have its RX line connected to the TX pin of the RS-232 cable (indirectly... it must still go through a signal level shifter). Similarly, your microcontroller TX line will be connected to the RX line of the DB9 pinout (again, through a level shifter). That's because "TX" and "RX" are designations from the standpoint of the DTE (your PC)
If you just want to get going quickly, buy a $10-$15 module that does this TTL to RS-232 level conversion for you.
I have this one and it works great
http://www.sparkfun.com/commerce/produc ... cts_id=449
This one appears a few bucks cheaper... a good description of DCE/DTE
http://www.hvwtech.com/products_view.asp?ProductID=289
To try out your RS-232 on your PC side, fire up Windows Hyperterminal application, loaded on all Windows PCs (Start -> Programs -> Accessories -> Communications -> Hyperterminal). First, name the connection then select the Windows COM port you'll be using. A common configuration is 8 data bits, no parity, 1 stop bit, and hardware flow control (CTS-RTS). But again, if you chose to short CTS-RTS at your microcontroller, that still considered hardware flow control-- the controls just happened to be pried wide open. Then you can select File -> Properties, "Settings" tab. Try an emulation of "VT100" or others. Also, under [ASCII SETUP], select the checkbox to echo characters typed locally. You may want to play around with sending additional line feeds or appending incoming line feeds, also available in that same window.
The point of this last step is that you will be able to type within hyperterminal. Send commands by typing them and hitting enter. The text will then be sent OUT the RS-232 port. Any text coming in just streams onto your Hyperterminal window. It's a great way to debug the communications without actually writing any programs to read/write to serial ports. Also, you can configure your microcontroller to scan the RS-232 port and take commands from things you type in Hyperterminal. I've done this and in 15 minutes, turned my PIC microcontroller into a simple "terminal". Of course, I programmed my PIC in a high-level C language (CCS Compiler), so that helps TREMENDOUSLY. RS-232 I/O becomes a 1-liner "printf" statement. My PIC terminal takes commands from me on my PC Hyperterminal, execute them as functions, then return data back to hyperterminal. FANTASTIC for debugging and very similar to what BASIC STAMP modules do.
Hope this helps!
- Bart McCoy
Rochester, MN
Theoretical aspects of serial communication go into data communications protocols, NRZ, multi-level signaling and error correction circuitry.
If you just want to build a link, then I'd first ask what kind of data rate you need (what kinds of volumes of data are you sending) and what ports do you have on your PC?
The easiest, by far, is RS-232. USB isn't too difficult if you use chipsets like the FTDI 232RL and use their virtual com-port drivers. The virtual com port drivers must be installed on a PC. Once those are in place, the USB port appears as any other COM port and you may read them on the PC using C programming language, Tcl/Tk, or whatever... but they become just another COM port.
First, I'd start with an understanding of RS-232. While there are many serial interfaces (e.g. SPI) RS232 is a common serial interface also used by PCs. Even if you want to use USB, you will likely use RS-232 on your microcontroller side (with TTL voltage levels, 0-5V) and then use a FTDI 232RL or equivalent to convert to the differential USB signals & protocol. The chip does the work for you-- just send TTL-level RS-232 IN and USB comes out!
A FANTASTIC place to start for RS-232 is the Wiki page. Go to Google and search for "RS232 wiki". The Wiki page should be right there and it will tell you much of what you need to know, including the signal voltage levels, data rates, pinouts of connectors and so forth.
The standard which RS232 uses has FAR more capabilities than is typically required for hobbiests. For example, using a simple DB-9 connector on PCs, you can establish an RS-232 connection with only Ground, TX and RX lines. That's enough to send data. Simply short the two CTS-RTS lines to each other and also short the DSR-DTR lines to each other on your microcontroller application side. That has the effect of proping the communication doors wide open so the PC is always has clearance to send data at any time.
But if you want to send more than an occasional data message and the microcontroller is busy doing other things, then consider adding the "CTS" and "RTS" lines to do hardware "flow control" so each side can say when the other side is "clear to send". That way, if your micrcontroller is busy, it can tell that to the PC, forcing it to wait 'till it's ready. But CTS-RTS flow control is NOT required. You just run the risk of loosing data, but you decide if that risk is big or not. Just Gnd, TX, RX. In fact, if your data flow is one way, you may only need a Gnd-TX or Gnd-RX!!
Sending serial data from a microcontroller to a PC requires a signal-level translation. RS-232 hardware signals ranges from -3 to -15V and +3 to +15 V. Microcontrollers are more like 0-5V or 0-3V. Those don't line up, so you need to use a chip like a "MAX232", by far the most popular for hobbiests. The chip is super easy to use and only requires a couple extra cap components to use.
For implementing this in robotics, I'd HIGHLY recommend the book, "Programming Robot Controllers" by Myke Predko,
http://www.amazon.com/Programming-Robot ... 0071408517
He discusses how to do the real RS-232 hookup (what I've described above) and why you want to short the CTS-RTS lines and short the DSR-DTR lines on your application.
A NOTE: When dealing with anything RS-232, BE CAREUL with the names. "TX" is a transmit line for someone... but who? The transmit on one side must go to a receive on the other side. Someone gets to transmit on the TX line while someone else must receive on the TX line.
To help with this distinction, one side (the PC) is often dubbed the "DTE" (Data terminal equipment-- the PC) and the other side is dubbed the "DCE" (data communication's equipment-- the microcontroller). This is a throwback to the days when terminals communicated with modems via RS-232.
TX (pin 3 on a DB 9 connector) means "transmit line" from the perspective of the DTE (computer/PC). Therefore, your microcontroller (DCE) will have its RX line connected to the TX pin of the RS-232 cable (indirectly... it must still go through a signal level shifter). Similarly, your microcontroller TX line will be connected to the RX line of the DB9 pinout (again, through a level shifter). That's because "TX" and "RX" are designations from the standpoint of the DTE (your PC)
If you just want to get going quickly, buy a $10-$15 module that does this TTL to RS-232 level conversion for you.
I have this one and it works great
http://www.sparkfun.com/commerce/produc ... cts_id=449
This one appears a few bucks cheaper... a good description of DCE/DTE
http://www.hvwtech.com/products_view.asp?ProductID=289
To try out your RS-232 on your PC side, fire up Windows Hyperterminal application, loaded on all Windows PCs (Start -> Programs -> Accessories -> Communications -> Hyperterminal). First, name the connection then select the Windows COM port you'll be using. A common configuration is 8 data bits, no parity, 1 stop bit, and hardware flow control (CTS-RTS). But again, if you chose to short CTS-RTS at your microcontroller, that still considered hardware flow control-- the controls just happened to be pried wide open. Then you can select File -> Properties, "Settings" tab. Try an emulation of "VT100" or others. Also, under [ASCII SETUP], select the checkbox to echo characters typed locally. You may want to play around with sending additional line feeds or appending incoming line feeds, also available in that same window.
The point of this last step is that you will be able to type within hyperterminal. Send commands by typing them and hitting enter. The text will then be sent OUT the RS-232 port. Any text coming in just streams onto your Hyperterminal window. It's a great way to debug the communications without actually writing any programs to read/write to serial ports. Also, you can configure your microcontroller to scan the RS-232 port and take commands from things you type in Hyperterminal. I've done this and in 15 minutes, turned my PIC microcontroller into a simple "terminal". Of course, I programmed my PIC in a high-level C language (CCS Compiler), so that helps TREMENDOUSLY. RS-232 I/O becomes a 1-liner "printf" statement. My PIC terminal takes commands from me on my PC Hyperterminal, execute them as functions, then return data back to hyperterminal. FANTASTIC for debugging and very similar to what BASIC STAMP modules do.
Hope this helps!
- Bart McCoy
Rochester, MN
Overall, a good description. I definitely do not recommend using RTS/CTS. At least initially. I've done a ton of serial port work with micros and have yet to use HW signaling (RTS/CTS). Just make sure to not select it in your terminal program. For a beginner, I think it will just add complexity. If you are doing some sort of data communication then maybe it will be of use. Note that serial bootloaders for the PIC and other uCs work just fine with out it.
What ever micro you choose, there will be lots of info on the serial (actually async) interface. Look for data sheets, application notes and so on. For the PIC micro family there is a huge body of info on the web.
Note that there is some confusion out there about the terms RS232, UART, Asynchronous and serial.
RS232 is just a signaling spec. wires, connectors and voltage levels.
Asynchronous is the name of the protocol on the wires (NRZ). It doesn't have an explicit clock but rather an implicit clock and start and stop bits.
UART is a Universal Async Receiver Transmitter. A piece of hardware that implements the Async protocol.
Serial is simply a way of sending data 1 bit at a time (vs parallel). Async is a serial protocol.
What ever micro you choose, there will be lots of info on the serial (actually async) interface. Look for data sheets, application notes and so on. For the PIC micro family there is a huge body of info on the web.
Note that there is some confusion out there about the terms RS232, UART, Asynchronous and serial.
RS232 is just a signaling spec. wires, connectors and voltage levels.
Asynchronous is the name of the protocol on the wires (NRZ). It doesn't have an explicit clock but rather an implicit clock and start and stop bits.
UART is a Universal Async Receiver Transmitter. A piece of hardware that implements the Async protocol.
Serial is simply a way of sending data 1 bit at a time (vs parallel). Async is a serial protocol.
Who is online
Users browsing this forum: No registered users and 54 guests