CH340 / CH330 for commercial crowdfunding product - Page 1
Forum section: electronics / beginners

author: mohf
author_rank: Contributor
timestamp: April 26, 2019, 11:49:48 am
content: Hi,Many IC's can do USB to UART, not many IC's are under $1 at quantities starting 1k.At just $0.3, the CH340 is extremely famous with Chinese Arduino clones.What is your opinion on commercial products using CH340?Edit: I'm mostly interested in driver compatibility and usage by n00bs / non-engineers.

author: exe
author_rank: Unknown
timestamp: April 26, 2019, 11:55:14 am
content: Never had issues with them, although, not sure if they are even genuine. I have them on several devboards from aliexpress. There is also CP2104 popular, no problem whatsoever. But I'm not an advanced user, I didn't do any benchmarks, etc.

author: DDunfield
author_rank: Regular Contributor
timestamp: April 26, 2019, 12:06:48 pm
content: My USB<>serial of choice these days.Had issues with others - mainly driver problems (some intentional, some not)Dave

author: Brumby
author_rank: Unknown
timestamp: April 26, 2019, 01:06:05 pm
content: My first experience some years ago had me hunting around for a driver - but it wasn't too much of a chore. Once found and installed, I had no problems whatsoever.Finding a driver these days is a lot easier.Plus it has the benefit of not having to wonder about FTDI hassles. (That whole fiasco was a stupid move.)

author: madires
author_rank: Super Contributor
timestamp: April 26, 2019, 01:17:26 pm
content: I don't see any particular issue with that. Linux is a no-brainer (kernel provides the driver) and for Win/Mac I'd suggest to bundle the driver with the software.

author: Kalvin
author_rank: Super Contributor
timestamp: April 26, 2019, 03:57:56 pm
content: Some (most?) CH340/CH341 USB-to-serial adapters in the market do not contain unique serial numbers but contain always zero as the serial number. This makes using multiple adapters at the same time in a single PC a bit complicated as one cannot select programmatically the correct serial port according to the device serial number.So, I suggest to select a device which contains unique serial number, or select a device which allows setting the serial number. Some CH340/CH341 variants contain built-in EEPROM which holds the serial number. Not sure whether the serials numbers are unique after leaving the factory - nor how the user can change the serial number. Probably there is a utility for setting the unique device serial number.If I remember correctly, there is a Windows-based utility for setting the serial number of the CP21XX-devices.

author: bson
author_rank: Unknown
timestamp: April 27, 2019, 02:57:05 am
content: The CH340 ICs work fine. Couldn't ever get the software they provide to reprogram them over USB. They need a lot of external components including a crystal.CP2102N doesn't need as many external components and they have vastly better tools, like to customize them with your product name so people looking at device manager, lsusb, or Apple's system report know what it is.

author: langwadt
author_rank: Super Contributor
timestamp: April 27, 2019, 03:08:16 am
content: afaiu the guys running grbl on arduinos with CH340G chips have had problems with bytes getting lost

author: oPossum
author_rank: Super Contributor
timestamp: April 27, 2019, 04:34:51 am
content: There are currently six chips in the CH340 family. Three do not require a crystal, one has internal EEPROM.I am using CH340C and CH340E at 2 mbps and have yet to see any problems.

author: DDunfield
author_rank: Regular Contributor
timestamp: April 27, 2019, 10:57:41 am
content: Quote from: bson on April 27, 2019, 02:57:05 amI've had problems with the CP2102 .. specifically there's something in the windows driver that affects the USB driver chain timing.Currently working on a project that is STM32 based and has a CP2102N for the debug/maintenance port. When the USB line is connected, the ST-LINK simply doesn't work. Verified on several different systems. No way to know what else it causes issues with, but not worth the risk.CH340 has no such issue. FTDI does not have this specific problem, but the pack of rabid dogs trying to kill your product after it's in customer hands removes them from the equation - manufacturer purchasing agent finds a "cheaper" source of the parts and they don't notify you because "it's the same part". All of a sudden you have a 100% failure rate on your next run, AFTER it has passed factory tests, been shipped to customers and windows has updated their drivers... FTDI provides no tool to validate that the chips used in a production run are "FTDI approved".So CH340 is what we are using now. So far it's been good.Dave

author: Peabody
author_rank: Super Contributor
timestamp: April 27, 2019, 02:01:41 pm
content: I believe there is a problem with the new CP2102N, as opposed to the old CP2102. Something on their forum about that. Also, I believe all the CP21xx parts are strictly 3.3V, whereas the CH340x can be either.

author: mohf
author_rank: Contributor
timestamp: April 27, 2019, 04:38:39 pm
content: Thanks for the replies, it seems the CP21** and FTDI variants are not really better.Quote from: bson on April 27, 2019, 02:57:05 amI'm planning on using CH330, which seems to be the same as CH340 except its SOIC-8 and only needs 1-2 decoupling caps

author: Rick Law
author_rank: Super Contributor
timestamp: April 27, 2019, 09:33:21 pm
content: There was a good discussion on CH340 on this forum not so long ago. You will find many other useful comments there on the user's view of the CH340. I commented in general positively about CH340 but negative-to-neutral in the non-uniquely way it ID itself to the OS. Here is exactly what I said there:Quote from: Rick Law on March 09, 2018, 11:54:18 pmhttps://www.eevblog.com/forum/beginners/problem-with-ch340-cheap-arduinos-in-windows-10/]https://www.eevblog.com/forum/beginners/problem-with-ch340-cheap-arduinos-in-windows-10/

author: madires
author_rank: Super Contributor
timestamp: April 28, 2019, 10:18:40 am
content: Isn't it the default behaviour of Windows to assign the COM port number based on the USB port? There aren't much users playing with the registry to attach a fixed COM port ID to a specific device.

author: DDunfield
author_rank: Regular Contributor
timestamp: April 28, 2019, 11:30:09 am
content: Quote from: madires on April 28, 2019, 10:18:40 amWindows assigns USB->COM ports on the USB port AND the serial number of the device.Plug one device into one USB then another, you will have two serial ports reserved.Plug a different device into the same two USB ports, you will have two more (4) serial ports reserved.Windows allows a max. 256 COM ports, so if you are in an application where you attached a lot of devices, you need to clear them out from time to time.I recently did a windows based tester which interfaces to the DUT via the maintenance port (USB->Serial) and at startup and every 50 units tested, I go in and clear out all USB->Serial devices of the particular PID/VID we are using.Dave

author: Rick Law
author_rank: Super Contributor
timestamp: April 28, 2019, 07:46:41 pm
content: Quote from: DDunfield on April 28, 2019, 11:30:09 amThat serial number for CH340 is apparently missing or not available with the standard Windows drivers.You can do quite a bit with the registry. With the FTDI (and driver), one could use PXE (pre-boot environment) to RegEDIT to give it a good friend user name,"permanent" port number, default speed/parity, (and anything else RegEdit can get to) and it will follow that specific card regardless of which USB socket you plug it in -- but you can't do that with CH340. You are tied to "the hole" you plug it into.Given the price delta between FTDI and CH340, I gave up and just accept the fact that it will ID itself based on which USB port I plug it into and keep rolling with CH340's.The "floating" com port assignment is more problematic than as first appears (think switching between PC's). Besides causing confusion at times, it does cause a good bit of inconvenience: On the PC side, you cannot have it hard code to a particular com port even for "quick and dirty" little things for experimentation. Powering down and switching plugs around doesn't always work because there may be port number conflict. So, codes on the PC side must carry the extra code needed to soft-select the port number, speed, parity, etc.When my old PC died, my whole load of "quick and dirty" tests codes went out the window. I retrofit some to have port selection dialog, but some test codes were just left dead till I really have a need for it.

author: oPossum
author_rank: Super Contributor
timestamp: April 28, 2019, 07:51:23 pm
content: CH340B does support an optional 8 character serial number using an external EEPROM. The other versions do not support a serial number by any means.

author: Rick Law
author_rank: Super Contributor
timestamp: April 28, 2019, 08:33:12 pm
content: For an end user product, one will need to think about how much inconvenience the user will need to endure and minimize that as much as possible.As an end user, I probably would not think "com 3" vs "com 7" (or whatever). I would like the product to work whether I plug it into the left side of the laptop or the right side of the laptop. So, if I started off with plugging it into the "first USB socket on the right side" and got it all set-up for my liking... There needs to be an easy way for me the user if next time I plugged it into the left side of the laptop. I would found it very annoying if I have to go through the entire setup process again - particularly if I have multiple devices and/or multiple laptops. And then, God forbid, I went and purchased a couple of USB Hubs... Now I have to go through the whole darn thing again...A simple drop-down on port selection probably wont work unless it is for technical users since typical users wont think ports. So, I think a way is for the codes to self-identifies - it scans the ports for the presence of the device. It tries to start using the same port as last time. If it is not found, then the user is given a choice to select port number or to scan for the device.I am sure many of you could think of a better way than what I just proposed. Any good way will do. As designer of the product, you just need to remember, each time I plug it into somewhere else, the port setting is different. Make it easy for the user when it happens.

author: DDunfield
author_rank: Regular Contributor
timestamp: April 28, 2019, 09:10:41 pm
content: Quote from: Rick Law on April 28, 2019, 08:33:12 pmThat's pretty much how seems to work under Windows ... every time you put the same device into a new USB socket, it gets assigned a new COM port.It would be nice if the OS just used the VID/PID/serial# as a unique identifier assigning it the same COM port no matter what USB socket it happens to be plugged in to. Although this would cause problem with CH340's which seem have default serial# == 0.I recently did a update program for a product using a USB serial port. When the user launches the update program, it tells him to connect the USB cable, and that if it is already connected he should disconnect it, and also that he should not connect/disconnect anything else while the update program is running. It then waits for a change in the serial ports configuration.If I see a serial port "go away", I issue a message that he should now reconnect it.If I see a serial port of the correct PID/VID show up, I configure it and attempt to do the update.This works quite well for in-frequent operations (such as updating), however it would become a PITA if you had to disconnect/connect the cable every time for more frequent functions. Perhaps default to the last COM port used, and offer a "Find my COM port" button doing the above when that COM port does not exist or does not respond as the expected device.A fully automatic way would be on application startup to scan the USB serial ports and try any that are the correct VID/PID ... but I don't like software automatically communicating with random COM ports unless I've activated a function documented to do that. The disconnect/connect method is nice because it does not actually communicate with a port unless it appears during discovery.Dave

author: Rick Law
author_rank: Super Contributor
timestamp: April 29, 2019, 12:42:06 am
content: Quote from: DDunfield on April 28, 2019, 09:10:41 pmYeah, that is THE PROBLEM, may be merely annoying but a problem none the less, that is why I pointed it out...Quote from: DDunfield on April 28, 2019, 09:10:41 pmGood that you brought it up. I forgot... Some devices (such as Arduino) would reboot even when you merely close and then reopen the COM port to it. That would annoy me a great deal if the Ardunio is running something like data collection.I like an auto scan, but I wish (yeah cold day in hell) that there is a non-disruptive method to scan for just a device ID.