CH340 / CH330 for commercial crowdfunding product

[mohf]

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.

[exe]

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.

[DDunfield]

My USB<>serial of choice these days.

Had issues with others - mainly driver problems (some intentional, some not)

Dave

[Brumby]

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.)

[madires]

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.

[Kalvin]

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.

[bson]

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.

[langwadt]

afaiu the guys running grbl on arduinos with CH340G chips have had problems with bytes getting lost

[oPossum]

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.

[DDunfield]

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.

I'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

[Peabody]

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.

[mohf]

Thanks for the replies, it seems the CP21** and FTDI variants are not really better.

They need a lot of external components including a crystal.

I'm planning on using CH330, which seems to be the same as CH340 except its SOIC-8 and only needs 1-2 decoupling caps

[Rick Law]

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:

...
So in Windows 7 does these CH340 stuff work fine?
...

Yes.  From personal experience these CH340 NANOs works just fine under Windows 7 (64 bit) and Windows XP sp3 (32 bit).  I have at least 6 of those and so far I have no problem with any of them.  My Win7 is x64, it may work with 32bit Win 7, but I cannot attest to if x32 would work as well.

For both Win7/WinXP, the main issue I see with these CH340 is each instance is not unique in the windows registry, so the COM port number depends on which USB slot it is in and NOT which CH340 NANO actually plugged in.  Whereas, I can make my 3 UNOs unique and change the Windows Registry so UNO1 is always COM6 regardless of which USB slot is hosting it, UNO2 is always COM7, so on.  Can't do that with CH340.

https://www.eevblog.com/forum/beginners/problem-with-ch340-cheap-arduinos-in-windows-10/]
[url]https://www.eevblog.com/forum/beginners/problem-with-ch340-cheap-arduinos-in-windows-10/[/url]

[madires]

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.

[DDunfield]

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.

Windows 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

[Rick Law]

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.

Windows 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

That 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.

[oPossum]

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.

[Rick Law]

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.

[DDunfield]

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...

That'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

[Rick Law]

...
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.
...
Dave

Yeah, that is THE PROBLEM, may be merely annoying but a problem none the less, that is why I pointed it out...

... 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

Good 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.