# Serial to USB converter

I have a DSP kit with a serial connection. Since, I am operating on my laptop, I do not have access to a serial port. So, I would require a Serial to USB converter

1. How do I create a Serial to USB converter?
2. Does it work at any baud rate, etc or is it fixed?
3. Can I access USB using hyperterminal, teraterm, minicom, etc or do I need some other software?
4. Any other considerations?

Thanks.

• Answers below.. I would be very vary of Prolific uSB adapters, I have had horrible experience with them. They loose bytes and drivers are buggy. FTDI is generally a safe choice. – Frank Aug 21 '11 at 14:31
• regarding the Prolific brand that @Frank mentioned - I've had issues with these at higher rates, e.g., 115200, such that they play with some devices and not with others, but at 9600 I've not seen a problem. And to be fair, I've seen a lot of other devices get sketchy at 115200 as well. – JustJeff Aug 21 '11 at 14:50
• So true @Frank! The range of quality poor to decent is amazing for a seemingly simple device. Good advice to stick to FTDI. – kenny Aug 21 '11 at 18:47

A1: By far the quickest and easiest method, and possibly the equal best, is to buy an existing USB to serial converter. I've seen these advertised on ebay for under $5 and those were probably not the cheapest. Here are ebay's listings of USB to RS232 converters - well worth looking at to see the range available (and prices). OK - checks - you're in Mumbai, India - checks -$US1.99 to India, free shipping!. You won't build one for that little - probably by a factor of 10 to 20!

Here are a few dozen photos and links to serial to USB converers - hover over the pictures for more information (on the page linked to above - not on the picture below) - click to go to the related site. A few examples - lots of choice !!! -

You can build your own using any of several available custom ICs created for this purpose - but doing that will cost you more than buying a prebuilt one.

A market leader but not the only source of ICs is FTDI corp who make these products.

A2. The most common units (usually a "cable" that plugs into a USB port) appear to a PC as a standard serial "comms port". They work across a range of baud rates. May be manufacturer dependant. Will be settable in software.

A3: As above - appears as a standard serial port.

A4: Some manufacturers peripherals do strange things and may not work for all converters. For example the PIC based PICAxe system uses a programming protocol that sends all data to and fro using RS232 "break signals". ie they do not use the data lines for information transfer. Some converters do not support the break signal.

You will need to know if your equipment is grossly non standard. If it is, some converters may work with it.

.

• What's the A# scheme for? – tyblu Jan 24 '12 at 14:12
4. Any other considerations?


Yes. Classic serial ports are ordinarily byte-oriented, ie, one character at a time with quite low latency. USB is inherently packet-oriented, with comparably high-latency. In other words, USB is great for moving a lot of data at once, but it's actually slower at moving tiny amounts of data. If you try to move a lot of data in tiny pieces with USB, you lose - badly.

For just typing on a terminal program talking to a modem or an embedded device, or even uploading files, etc, this is really not a problem, because single doses of the latency are small in human terms, and the USB can easily move blocks of data fast enough keep up with any serial baud rate.

But other protocols which depend on constant back-and-forth of short messages or single characters between a computer and a serial peripheral can slow to a crawl (or even mis-operate) when used with a usb-serial converter. If a computer does something like send a single character, and wait for the peripheral to respond before sending then next, then the character rate is determined by the latency for two entire usb packets - one to send a single character, and one to receive one (it may even be worse - the receive might at the lowest level involve poling). In today's world where USB-serial converters are as or more common than real serial ports, its important to design protocols so that you can send out a lot of data, before needing to wait for a reply. With legacy systems, you may get lucky and find it works fine, it may work but slowly, or it may not work reliably at all.

And even within a given protocol, peripheral, computer, and operating system driver, the design of the client software matters. I once encountered a piece of management software for an embedded device which had been written and tested by a contractor using a real serial port. It turned out to use some variation of .NET serial calls that turned out to be "watch the results crawl in" slow on a laptop with a usb-serial converter. My own previous simple win32 management tool for that device ran without apparently delay on the same laptop with the same converter. Perhaps I wrote better code, but given that the converter was my ordinary test environment, if there had been a similar problem with my code, I would have been lucky enough to find it while there was still time to fix the problem.

Moral of the rant in todays world, anything (hardware or even client software) designed to use a serial port should be tested for usability with usb-serial converters early enough in its development that the design can be changed to fix any issues discovered.

• Thanks for the elaborate explanation. It was quite interesting! :) – Neel Mehta Aug 21 '11 at 17:29
• Ditto +1. I've lived a lot of that pain and knowledge too! – kenny Aug 21 '11 at 18:45

You need something like a FT232:

FT232 Product page

USB to RS232 adapter with FT232