Alternatives to FTDI USB to UART converter

[MicroBoy]

I've been working in the past days in a microcontroller library compatible with FTDI drivers since all this circus began. It's based on a 32 bit ARM Cortex M3 NXP LPC1343 but i would like to migrate it to a LPC1347. It currently behaves internally as a FT245, but adding serial port commands and stuff it could easily behave as a FT232 too. Good news is that this microcontroller costs the same as a FTDI device, and you still have plenty of CPU power and peripherals to have your own code embedded all into a single chip. Firmware is also easily upgradeable via USB.

Still, cleanup and further comunity colaboration will be needed, as i only did this because i like reverse engineering stuff; Specially when someone f*ck with us.

Knowledge is power...

[nctnico]

Actually you can do the same with an LPC11U12 which is even cheaper than an FT232 but it will need an external crystal (just like the LPC13xx).

[MicroBoy]

Actually you can do the same with an LPC11U12 which is even cheaper than an FT232 but it will need an external crystal (just like the LPC13xx).

Yes.. you could. LPC11U12 is a Cortex M0 running up to 50Mhz. I was talking about LPC1347 because it haves internal EEPROM and a couple of peripherals more that may help to make a all-in-one solution. You could always add an external EEPROM to the other models too. 

[zapta]

Actually you can do the same with an LPC11U12 which is even cheaper than an FT232 but it will need an external crystal (just like the LPC13xx).

Yes.. you could. LPC11U12 is a Cortex M0 running up to 50Mhz. I was talking about LPC1347 because it haves internal EEPROM and a couple of peripherals more that may help to make a all-in-one solution. You could always add an external EEPROM to the other models too.

Check the LPC11U35.  It's less expensive than the LPC1347.

[benSTmax]

Any microcontroller solution is nice when you can do some other system logic in it as well(besides the usb-uart stuff)
Take for instance the LPC1347 or LPC11Uxx cases above.If you have FTDI emulation plus the rest of the logic in the system, this is definitely a winner.

[jboard146]

As to the PL2303 the windows drivers work, but the OSX and linux drivers are a nightmare. From a driver standpoint I'm ruling the PL2303 out.

[madires]

As to the PL2303 the windows drivers work, but the OSX and linux drivers are a nightmare. From a driver standpoint I'm ruling the PL2303 out.

I'm using PL2303 based adapters for years with linux without any problems. Actually, I prefer them over FTDI because I had some issues with FTDI based adapters. Even long term usage (24*7 for several months) works fine. I can't complain

[Chipguy]

Updated list, with rough pricing for 1pcs (tinkervolume)

Atmel ATMEGA16U2 with Arduino USBSerial Firmware (see Arduino UNO R3) (around $4)
ASIX MCS7810 (Price n/a) http://www.asix.com.tw
Cypress CY7C65211 ($2.61 Mouser) (with battery charger detection http://www.cypress.com/?mpn=CY7C65211-24LTXI
Cypress CY7C65213 ($2.44 Mouser) with battery charger detection http://www.cypress.com/?mpn=CY7C65213-28PVXI
Exar XR21V1410 ($5.11 Mouser) http://www.exar.com/connectivity/uart-and-bridging-solutions/usb-uarts/xr21v1410
Prolific PL2303HX (Price $0.80 ebay, Pin compatible to FT232R) http://www.prolific.com.tw/us/ShowProduct.aspx?p_id=156&pcid=41
Microchip MCP2200 ($1.94 Mouser) www.microchip.com/MCP2200
Microchip MCP2221 ($2.74)) http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP2221
Silicon Labs CP210x ($1.42 Mouser 2104) http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-uart-bridge.aspx
Texas Instruments TUSB3410 ($6.50 Mouser) http://www.ti.com/product/TUSB3410?keyMatch=tusb3410&tisearch=Search-EN
WCH-IC Chinese CH340 (ebay $0.50) http://wch-ic.com/product/usb/ch340.asp

[Chipguy]

Hi,

I played a bit more around with the Cypress CY7C65213 today.
Got 10 pcs in the SSOP case.

I managed to use them as a dtop in replacement but there are restrictions:
There is not really a 3.3V out like in the FT232RL.
Since I didnt use that and there is only the capacitor connected to the it was not a problem.

Driver modification:
I also modified the drivers to my own VID/PID.
It's a bit suboptimal since the actual virtual COM port name is really virtual coming out the Cypress driver.
I was not able to change the name of the Serial device like "Chipguys chip(COM10)", it just stays on "USB Serial Device(COM10)" or something like that.
There are 2 drivers needed and one is not even supported in the download package, no idea what's up with that.
Installing the RDK you get all the drivers in the Program directory, so installation works.
There are 2 directories "cyusb" and "cyserial3", then dubfolders for the OS and then x86/i64.
The filenames are all different so they actually could merge the content of these 2 into one, that would make installation much easier.
I have acutally done that and going to check it tomorrow on a win7/i64 system.

Cheers,
Chipguy

[Fungus]

What about drivers? That's important too.

The ATMEGA16U2 probably scores very high for driver availability/reliability, although they're the second most expensive choice. Arduino drivers are pounded to death all over the world every day, maybe even more so than FTDI drivers (yet FTDI claim that "driver quality" is the reason to choose them over the competition...hmmm, really?). Arduino drivers are completely open source so you don't have to worry about any dirty tricks.

Does anybody have experience with Microchip drivers? Their chips seem pretty attractive and are a lot cheaper than an ATmega.

[Monkeh]

Does anyone know if the SiLabs CP2104 is supported in Linux "out of the box"?

How on earth are we supposed to know how your kernels are compiled?

On the SiLabs website:
"*Note: The Linux 3.x.x version of the driver is maintained in the current Linux 3.x.x tree at www.kernel.org."
So as long as it is a recent Kernel [3.0.0+] the driver is built-in, anything lower in revision number, then the driver would have to have been manually included in the build [or, I suppose can be added as a module-- I haven't looked at the code].

Everything like this has to be manually included. The driver has been in-tree for over five years, that has no bearing on whether it's built into your kernel, supplied as a module, or not available.

[alper.y]

I have never used MCP2221 but after quickly skim MCP2221 datasheet noticed that it is possible to change UART parameters by sending commands like "GET_LINE_CODING" over serial port term as stated in 1.3.1 section at datasheet:

http://ww1.microchip.com/downloads/en/DeviceDoc/20005292A.pdf

If I understand right, chip will change some settings if an UART message contains "GET_LINE_CODING" string, right? Then should I say to user that "Please, don't transmit these special words, they are reserved."?

[Monkeh]

I have never used MCP2221 but after quickly skim MCP2221 datasheet noticed that it is possible to change UART parameters by sending commands like "GET_LINE_CODING" over serial port term as stated in 1.3.1 section at datasheet:

http://ww1.microchip.com/downloads/en/DeviceDoc/20005292A.pdf

If I understand right, chip will change some settings if an UART message contains "GET_LINE_CODING" string, right? Then should I say to user that "Please, don't transmit these special words, they are reserved."?

No.

http://www.usb.org/developers/docs/devclass_docs/CDC1.2_WMC1.1_012011.zip

[benSTmax]

Updated list, with rough pricing for 1pcs (tinkervolume)

Atmel ATMEGA16U2 with Arduino USBSerial Firmware (see Arduino UNO R3) (around $4)
ASIX MCS7810 (Price n/a) http://www.asix.com.tw
Cypress CY7C65211 ($2.61 Mouser) (with battery charger detection http://www.cypress.com/?mpn=CY7C65211-24LTXI
Cypress CY7C65213 ($2.44 Mouser) with battery charger detection http://www.cypress.com/?mpn=CY7C65213-28PVXI
Exar XR21V1410 ($5.11 Mouser) http://www.exar.com/connectivity/uart-and-bridging-solutions/usb-uarts/xr21v1410
Prolific PL2303HX (Price $0.80 ebay, Pin compatible to FT232R) http://www.prolific.com.tw/us/ShowProduct.aspx?p_id=156&pcid=41
Microchip MCP2200 ($1.94 Mouser) www.microchip.com/MCP2200
Microchip MCP2221 ($2.74)) http://www.microchip.com/wwwproducts/Devices.aspx?product=MCP2221
Silicon Labs CP210x ($1.42 Mouser 2104) http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-uart-bridge.aspx
Texas Instruments TUSB3410 ($6.50 Mouser) http://www.ti.com/product/TUSB3410?keyMatch=tusb3410&tisearch=Search-EN
WCH-IC Chinese CH340 (ebay $0.50) http://wch-ic.com/product/usb/ch340.asp

Hi Chipguy,
Could you put the Digikey prices for the chips above when asking for 1k pieces?
It seems the Mouser prices are higher than normal.
For instance, I checked the 1k price for CY7C65211 and I got back $1.606

[markb82]

If someone wants a very cheap solution, an attiny might be an option.  Use general GPIO for USB, limit to 1.5Mbps, and implement USB-CDC?  A google search reveals several people that have implemented USB-HID in an attiny.  Still would require loading firmware onto the attiny, and potentially maintaining it, so I'd personally use a dedicated chip (silabs), but a microcontroller solution is definitely doable, even in an MCU without USB.

[ve7xen]

How on earth are we supposed to know how your kernels are compiled?

Well, as I stated, I have no control over the end-user's embedded Linux, whether it was compiled in or included as a module [or not], is not up to me.  I checked, and it *is* included in the Kernel of my workstation, so no problem there.  I suppose the fastest way to test this is just plug it in and see what happens...  If it creates a new serial port when plugged in, then there is nothing more to do, if not, then it gets more complicated I guess, but not insurmountable.  If *I* were building such an embedded system, *I* would probably just compile these in, or at the very least compile the support in as a loadable module-- I have no idea what others might do though.  At least the source is available for tinkering, etc.

Also, if they took the time to compile in support for FTDI, there is a good chance that they also compiled in support for the CP2104...  We shall see I guess...

Thanks for the help...

Several of the options listed are CDC devices, which probably has the best chance of support across Linux kernels, being a USB standard device class. I believe it will also work out of the box on OSX. Windows for some stupid reason requires an INF file despite the driver itself being included. They may have somewhat less functionality than proprietary chips, but IMO the class-compliant nature is a big selling point.

[Bud]

Prolific PL2303HX (Price $0.80 ebay,

eBay, eh ?  Thank you but no thank you.
 

[miguelvp]

Hi Chipguy,
Could you put the Digikey prices for the chips above when asking for 1k pieces?
It seems the Mouser prices are higher than normal.
For instance, I checked the 1k price for CY7C65211 and I got back $1.606

Or order directly from Cypress, cheaper and probably has free shipping but not sure about that.

http://www.cypress.com/?id=4865

[sleemanj]

It should be noted that the MCP2200 does not provide control over DTR, I don't know about the other MCP part.

[benSTmax]

MCP2221 only provides the UART Tx and Rx.
When the other signals (RTS, CTS, DTR, ...) are needed other chips might be better to use (CY7C6521x, PL2303, CP210x, ...)

[alper.y]

I have never used MCP2221 but after quickly skim MCP2221 datasheet noticed that it is possible to change UART parameters by sending commands like "GET_LINE_CODING" over serial port term as stated in 1.3.1 section at datasheet:

http://ww1.microchip.com/downloads/en/DeviceDoc/20005292A.pdf

If I understand right, chip will change some settings if an UART message contains "GET_LINE_CODING" string, right? Then should I say to user that "Please, don't transmit these special words, they are reserved."?

No.

http://www.usb.org/developers/docs/devclass_docs/CDC1.2_WMC1.1_012011.zip

OK, it seems that this is a request for CDC devices as stated in PSTN 1.20. When I click to connect a serial port, terminal software, or OS anyway, sends this request and chip responds to that command. Got it!

Maybe I shouldn't read datasheets before going to bed. 

[mvta]

Hi Chipguy,
I am Madhura, Applications Engineer from Cypress Semiconductor. I went through your survey and first of all, thank you for giving such detailed feedback on CY7C65213 device. At Cypress, customer's feedback is always valuable and we always incorporate their feedback in our next revisions of software, drivers, firmware or documentation.

You have mentioned that, you faced some issues while installing drivers. You manually bound drivers to CY7C65213 device after installing USB-Serial SW and drivers.
Now, we are in process of updating our USB-Serial SW, so that automatic installation of drivers happens, if you download and install USB-Serial SW. So, manual binding of drivers won't be required. We will update the same our webpage:
http://www.cypress.com/?rID=83110

Also, we would like to inform you that our USB-Serial drivers are WHQL certified and thus automatically get installed on your PC if your PC is connected to Internet. It will be great help for us to identify the issue, if you can provide following information to us:

1. When you connect the device to PC, was your PC connected to Internet?
2. Did you see any window, showing driver installation through Windows update?

We are looking forward to hear back these answers from you.
Thank you for choosing Cypress product.

Thanks,
Madhura
Cypress Application Engineer

[Royce]

What about the CP2110? Has anyone used that?

That part was mentioned over in the bashing thread around page 35 or so. Apparently it is a HID device with a custom "report" or something. As I understand it the basic result is that the driver winds up moving to your PC software (you have to know how to interact with the custom report) and the actual driver is the OS supplied USB HID driver.

[Chipguy]

Hi Madhura!

Thanks for participating in this thread.

Here is what I was working with the other day:


I got the little module from Farnell,nice and neat.
My experiences with the driver was that there are two different driver needed. However the WHQL driver did only supply one of these drivers. Not sure if the virtual COM port would work but at least the customers would end up with one unknown device with no drivers.
That would raise a lot of support questions.

What I got after the extraction of the downloaded driver package was this:
\CyUSBSerial_driver_v3.13.0.20_WHQL_CERTIFIED\cyusbserial\[Operating System]\[x86 or x64]\[driver files]

Within the files there is of course also an inf file called "CypressUsbAndBus.inf"
It contains bindings to the device "USB\VID_04B4&PID_0003"

This driver installs fine but the Cypress CY7C65213 expresses a second sub device which ID is "USB\VID_04B4&PID_0003&MI_02".
This ID can not be found in the WHQL drivers.

However having also installed the RDK (also downloaded from the website) I found that all the drivers are copied to:
C:\Program Files (x86)\Cypress\CYUSBS232 RDK\1.0\driver\cyusb3
C:\Program Files (x86)\Cypress\CYUSBS232 RDK\1.0\driver\cyusbserial

Now, the "...\cyusb3" directory is important, it contains the inf file "cyusb3.inf" which contains all the sections to install

"USB\VID_04B4&PID_0003&MI_02".

After tinkering around I finally got everything installed and the device list now looks like this:



I am not sure if the Cypress IC on the module needs to have a different setting somewhere not to express that "...&MI_02" device, but I couldn't find anything obvious. The only setting that could affect it is "CDC" but I think I am going to need that setting since I need to use a virtual COM port.
I have modified the drivers files assortment and put everything I found in "C:\Program Files (x86)\Cypress\CYUSBS232 RDK\1.0\driver\cyusb3" into the "cyusbserial" folder. The files have different names so it's no problem and the installation is much easier. Only one directory to point the drivers at.

I didn't check if they install from the Internet, since my tests need to make sure that the drivers we deliver work on their own.

Ok that's for the drivers.

Concerning the hardware I only have one BIG wish (Not having this is really a big disadvantage)
An auto RS485 choice for the GPIO ports like the FTDI's do have.
That's all.

[dannyf]

Another option would be to use those mp3 player chips: they inevitably have a usb controller, and many have uart too. So making them into a bridge is simple.

And those chips are too cheap: pennies each.

The only downside is that if you are not buying in 10s of thousands, they don't want to talk to you. But it is a business that people like appotech can easily get into and dominate, at least on costs alone.