USB to RS232 one chip solution

I've seen some parts FT232* and the like but not familiar with them.

What is the current state of the art chip solution for rs232 to usb conversion?

I just have some simple 8 bit no parity 1200 baud I'd like to get into USB.

Will I have to write any software for the chip or can I simply set the chip by some pin manipulation?

Something simple/cheap/popular.

Thanks kindly for any help.

Reply to
mkr5000
Loading thread data ...

formatting link

Saelig has this one, you set your pc for a virtual comm port through software they provide. You write your apps as if you were writing to a standard RS232 comm port! No messing with USB drivers.

Reply to
ScadaEng

Have a look at

formatting link

Drivers are downloadable for Windows, Mac and Linux. You "set" the chip (baud rate, parity, etc) using standard O/S based methods.

Reply to
JW

The Silabs CP2103 works well, and they have a demo board for about $30, but the part is in a fine pitch DFN-28. There is also a TI TUSB3410 and a TUSB5052 that has two UARTs and a 5 port hub.

You might also look at the Microchip PIC18F2450 and similar parts. They have a full speed demo board (PICDEM FS USB) with a lot of free software for about $40, and I have made a USB-Serial converter with that as well. You don't have to do anything with the firmware, but it's good to have access to the source so you can tweak it if you need to. And it's useful to see what's going on "under the hood".

For any of these, you will also need something like a MAX232 to get RS232 voltages. The ICs are in the $5-$10 range in single quantities.

Paul

Reply to
Paul E. Schoen

I need an education on these parts.

I have an RS485 to RS232 transceiver that I use, the TI SN75176.

I simply want to update the serial port to USB.

Looking at that CP2102, it looks like I can simply supply the SN75176 RS232 to the UART.

So, when I build my interface boxes I then program the chip's eeprom via the USB port and my PC?

Just install their software and it sets the baud rate and all the other parameters? Then it's a done deal?

The drivers are just for programming -- not needed after the chip is burnt?

Thanks.

Reply to
mkr5000

Yes... in their most generic configuration, these sorts of ICs (I'm familiar with the ones from FTDI) really do take USB in one side and provide a (5V) RS-232 port on the other side. The manufacturer provides the device driver so that, as far as your operating system is concerned, you just have a new COM: port. (Note that this implies you need a relatively modern OS with USB support... if you have some old industrial controlling running DOS, for instance, it's a lot iffier whether or not you'll find a driver without having to have someone custom program it for you. But for Windows, the Mac OS, Linux, etc., this is all easy.)

Yes, and strictly speaking you don't even have to program the chip's EEPROM if you're happy with the defaults (i.e., the name of your device -- without programming the EEPROM it'll just show up as something like, "USB to RS-232 Converter" rather than "MKR500's Cool Widget").

Yes, you set the baud rate, pairty, data/stop bits, etc. using the exact same method you would for a "regular" RS-232 port.

At least for the FTDI chips, the newest versions of Windows (e.g., Vista) even come with the driver pre-loaded for you when you install the OS.

No, the drivers are always need (just as a driver is always needed for a regular serial port in a modern OS), but the operating system takes care of keeping them around. You use a little program (it's called "MProg" in the case of FTDI chips) to program the EEPROM -- it communicates through the regular operating system driver. In fact, if you want to, FTDI provides a .DLL so that your programs can talk a bit more "directly" to the chip as well. This gives you the advantage that you can use features that a "regular" RS-232 port doesn't provide. E.g., bit-bang the pins to load FPGA bitstreams, setup "weird" serial modes (like I2C or SPI) that regular RS-232 ports can't, etc... but this is all optional. Any program that knows how to talk to a regular RS-232 port (e.g., Hyperterminal) will have no problem talking to your device.

Go poke around FTDI's web site and download some of their documentation -- this should then become somewhat clearer.

---Joel

Reply to
Joel Koltner

FTDI FT232R. Available as chip, module and even chip-in-a-cable versions (TTL232R) . Can produce a TXEN signal for driver enable in RS485 apps. Good driver support for various OSs. You can use their virtual COM port (VCP) driver to make it look like a COM port, or their D2xx drivers which have some advantages, like not having to figure out what COM port got assigned to it, higher baudrates and better control over timing.

You can configure a number of things using their MPROG utility, like options for the extra IO lines, as well as programming custom product/vendor IDs so you can customise their drivers to make it look to the user like a 'proper' dedicated USB device and not a COM port. This is all easy to do - just look at the help for the MPROG utility at ftdichip.com

Reply to
Mike Harrison

Ok thanks guys.

This will be fun to play with.

I'm "attempting" to write a simple application using visual basic, so when I'm finished, I'll have to include the driver.

You would think that if you a properly operating USB device, that Windows would automatically recognize it and get it up and running?

Guess not.

Why is that exactly? What is in the driver that Windows XP would need?

(Just learning).

Reply to
mkr5000

If you really need RS-232 hardware levels:

formatting link
will give you some choices. To my knowledge, it has never been done in one IC.

However, as long as it is a micro or similar that you are supporting, then you don't need to do the double conversion to/from hardware RS-232, you skip it, and connect one of these direct to your micro:

formatting link

Hope this helps

Cheers Don...

--
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
 Click to see the full signature
Reply to
Don McKenzie

sorry, that first URL was incorrect.

formatting link
will give you USB to RS-232, and more usb to TTL options.

Cheers Don...

--
Don McKenzie

Site Map:            http://www.dontronics.com/sitemap
 Click to see the full signature
Reply to
Don McKenzie

The downside of USB I suppose is the complexity of it's approach and hence, the inability of Windows to integrate with it in a plug and play fashion?

It seems to me I've had some devices that were plug and play without drivers (if I remember right) and some where there were drivers that needed to be installed.

I wish I knew more about why that is.....must be some very specific information required in code, I guess.

Reply to
mkr5000

USB is considered to be 'plug and play' but pretty much all USB devices except for keyboards/mice and disk drives (including flash ones) will require drivers to be installed... in the windows world.

A lot of linux distributions come with drivers for assorted USB-serial widgets already installed.

Actually there is a downside to the USB serial devices. Latency is often substantially higher than a real serial port. You can shove a lot of data through the things, often at higher baud rates than the old serial port speeds. But because of the packetized way USB works, you want to write software protocols that stream data and use block writes to the O/S serial port layer, because lots of little few- or one-character writes, or worse, write and wait for read, will slow you down due to the latency hits. For a lot of applications this is not an issue, the latencies are small, but if you need to move a lot of data quickly you have to think about keeping it flowing smoothly.

Reply to
cs_posting

Well... the better perspective is that ALL hardware needs a device driver as such in a modern operating system, the question is just whether the OS manufacturer (e.g., Microsoft) already *included* that driver when the OS was installed or if the end user needs to provide it themselves.

Yes, Windows comes with literally thousands of drivers included, but that's nothing compared to the many tens or even hundreds of thousands of different bits of hardware out there.

Compared to a "regular" RS-232 serial part, USB is many times more complex -- on the order of, e.g., a PCI bus. But, there's something else going here that many people don't realize: With RS-232, someone has to sit down and define a protocol for the device in question (unless it's just, e.g., a terminal program!), and implementing that protocol ends up in an "application." In a sense, then, the protocol handling code *is* a "driver," it's just installed by "setup.exe" rather than the plug-and-play manager. With USB, while there's often still some amount of protocol that needs to be defined for custom devices too, it's nowhere near as much as with RS-232 -- at least if the RS-232 device needed comparable robustness: The Windows USB drivers take care of loading the right driver based on the device attached, it takes care of buffering USB packets and sending re-tries upon errors, and takes care of scheduling for time-critical (isochronous) transfers. Hence, RS-232 vs. USB isn't really that different in that both need drivers, it's just that the division of *where* the driver ends up (as a Kernel-mode device driver or a user-mode application) has been set up so as to try to keep some of the complexity of USB from having to be dealt with in user-mode code.

---Joel

Reply to
Joel Koltner

I follow you....exactly what I needed to know.

I guess I was just naive in thinking that along with a new standard like USB, that there would also be more progress toward compatibility between devices and manufacturers, etc.

Sometimes my dreaming interferes with my sense of logic.

Reply to
mkr5000

Hi,

formatting link

formatting link

Good luck

Marte

Reply to
Marte Schwarz

There has been some... keyboards, mice, other "human input devices" (joysticks, steering wheels, etc.) and mass storage devices (USB hard drives and memory sticks) are the most obvious examples. There are USB standards for all sorts of devices, but there's the usual problem that the standards are only drawn up for "popular" devices, so a lot of industrial devices will never make it, plus of course there are devices such as printers, scanners, web cams, etc. that can differ so much in their capabilities that a "one size fits most" solution doesn't actually cover that many different models. Actually, I think they could have done better in the case of, e.g., printers, but I suspect that the current marketing model of low-end printers -- sell the printer for literally next to nothing, often $29 or less!, and make money from the sales of ink -- forces the printers themselves to be so stripped-down that they're literally not "smart enough" to be able to support any reasonable standard.

---Joel

Reply to
Joel Koltner
Reply to
Brendan Gillatt

Although there is no reason why Microsoft could not have included a suitable driver within XP.

I was impressed that my two USB:RS232 dongles "just worked" under linux. (An FTDI one and some Chinese noname thing - Prolific?).

--

John Devereux
Reply to
John Devereux

I can second both the FTDI usb chip-recommendation, and the recommendation to use the d2xx drivers.

The advantage of going the Virtual Com Port route is that you can use standard windows com-port calls.... where you have to use FTDI's calls with the D2XX dll. The D2XX drivers get you closer to the hardware, and you can talk to the chip without figuring out how they mapped the various functions into the standard microsoft serial framework.

FTDI's chips, drivers, documentation, and support are all top notch in my book. I've had great success using them in a project of mine.

HTH

Keith

Reply to
Keith M

I've had great success, but my experience with them has been a little more mixed, primarily relating to their bugs: They seem to go out of their way to not mention them! Their v2.02 Windows drivers had a bug when used in a multi-threaded application, and while -- after we discovered it -- they confirmed it was there (and six months later came out with the current release that fixes it), but how many developers wasted hours discovering it and isolating it when a couple of lines in an errata.txt file would completely eliminate the problem? Similarly, I found out the hard way that the general purpose high-snoot serial port in the 2232 parts has a few glitches -- not every supported feature can be used simultaneously, but of course this isn't documented anywhere. Additionally, some of the features require non-obvious initialization sequences to work around bugs: If the documentation has sample code that does something weird or non-obvious, in most cases what's going on is a bug work-around, and you should do it the same way if you need your code to work.

The bugs do only start showing up when you do start getting "fancy" with the part -- if you just need a generic serial port in a generic (non-multi-threaded) application, they'll work just ducky. I definitely recommend people try them out -- they're as good as any alternatives I'm familiar with.

---Joel

Reply to
Joel Koltner

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.