I’ve just mentioned Silabs CP2104 USB to UART chip price had increased, and indicated WCH CH9102F chip could be used as an alternative instead in a post about LILYGO T-Display boards.
I had never heard about CH9102 chips before (CH9102F and CH9102X), so I decided to investigate a bit more by checking out both CH9102 and CP2104 datasheets.
CH9102X is pretty similar to CH9102F but offered in a 5x5mm 28-QFN package with extra GPIOs. Back to the main contenders… According to LILYGO, one of the differences between CH9102F and CP2104 is the former is limited to 4 Mbps while the latter supports up to 12 Mbps data transfers.
I got the information from the table above on T-Display ESP32 Aliexpress page, but the datasheets have a bit more context:
- CP2104
- “USB Specification 2.0 compliant; full-speed (12 Mbps)”
- UART – “Baud rates: 300 bps to 2 Mbits”
- CH9102 – “Hardware full duplex serial UART interface, integrated transmit-receive buffer, supports communication baud rate varies from 50bps to 4Mbps.”
So CH9102 might actually support higher bitrates. This may not matter much for ESP boards as the maximum baud rate I’ve seen was 1,500,000 bps with utilities such as esptool. Both Windows and Mac OS support CH9102, and the chip probably works in Linux out of the box, but if not WCH “VCP” driver is also available.
Since the decision to provide an alternative was the lower cost, let’s check CP2104 pricing info on LCSC…
CH9102F is listed in LCSC, but shown as “Discountinued” in LSCS, which probably just means there’s no stock. Octopart has never heard of that chip apparently, so instead, I went to 1688.com…
It’s a good thing to have CH9102F as a second source, even if your hardware is not cost-sensitive, just in case CP2104 stock runs out…
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
I tried to buy some CH552T or CH552G on LCSC which previosuly hold a large stock of those cheap USB capable 8bit MCUs. Nowadays the stock is zero. I tried to order on taobao as a last resort, but got 2 orders cancelled bacause of the chip shortages (the sellers on TB could not deliver to the despatching agent). 1688.com seems to be related to TB as when I tried to search for CH552T on their web search they asked me to login to TB.
Just searched the CP2104 on 1688 and got different results. From about 4.90 yuan ($0.76) to more than 15.80 yuan ($2.45). Probably the more cheap is not original.
Typically the difference is minimum order amounts. The $2.45 is Q1. For $0.76 you have to buy entire reel of 2000-3000 parts. In general the listings are not clear on this and you have to ask. They are not consistent about whether Q1 is one chip or one reel.
They compared with CH340, but one problem of CH340 precisely is high bit rates which are unstable due to lack of vendor documentation of internal registers, preventing large packets from being used, which are absolutely mandatory to support the 1.5 Mbps that rockchip devices use by default. I tried to change that but that broke for other users on small transfers and the change had to be reverted 🙁 So now I’m going to stay away from CH340 for anything higher than a few hundred kbps.
They’ve created a github account and started uploading their code there:
https://github.com/WCHSoftGroup
They even say the in kernel ch340 driver is buggy and they wish their driver had been used instead. 😀
Oh thanks, with a bit of luck we could figure there the hidden bits! They’re really exagerating by criticizing that their driver was not used, they ought to propose it in the first place!
I encouraged them to submit it.
https://github.com/WCHSoftGroup/ch341ser_linux/issues/2
or you can do it for them if they are uninterested.
>or you can do it for them if they are uninterested.
Trying to push >300 commits for a niche ARM SoC is enough for me right now. I think if Willy could use their code to work out how to make his highspeed changes work that would be the best result.
A quick glance at their code makes me think it would be a lot of work to clean it up and send it as a replacement for the existing driver anyhow. They should probably dump their driver entirely and just fix the bugs they think are in the kernel one.
Yep. I’m extremely short of time these weeks but I’m keeping an open tab on it in hope to be able to find some time to compare their setup code with the mainline one and figure what has to change to force the chip to emit packets on 64 byte boundaries when the xfer size is increased beyond this.
Seems to me that a full-speed USB device is never going to do 12Mbps at the UART port. If we allow for full-duplex, and take off the USB overhead, then 4Mbps would be a good achievement even with nothing else on the bus.
CP210x has an EEPROM on the chip which can be programmed via USB.
CH9102 does not feature EEPROM which can change PID (Product ID) string, etc.
CP2104 has 4 gpio pins, which could be used under Linux with sysfs.
There was an accepted kernel patch to expose them under /sys/class/gpio by some hungarian guy that made this usb-serial board, but for the CP2102N if I remember:
http://www.zoobab.com/ch341-usb-spi-i2c-uart-isp-dongle#toc13
I think the patch has been accepted in mainline, and now you might have a libgpiod USB device where you can control the GPIO pins without having to write your own libusb commands.
I guess it might be doable to do the same with this WCH chip, like it was done for the GPIO pins of the CH341A.
FYI, the driver for macOS is not in a good state yet, see https://github.com/Xinyuan-LilyGO/LilyGo-T-Call-SIM800/issues/139.
That’s it, @Ivan Grokhotkov.
CH9102F really doesn’t work at all in Mac OS.
It’s not just that the CP2104 price is increasing, for some reason Silicon Labs has designated the very popular CP2104 USB 2.0 to UART bridge as Not Recommended for New Designs (NRND). Adafruit just did “The Great Search” for a replacement and settled on the CP2102N as the next-best fit, but it’s not a pin-for-pin drop-in. The Adafruit search video is on their Blog [September 14, 2021 AT 11:13 am]. See here:
The Great Search: Alternative for CP2014 USB to UART #TheGreatSearch #DigiKey @DigiKey @Adafruit
https://blog.adafruit.com/2021/09/14/the-great-search-alternative-for-cp2014-usb-to-uart-thegreatsearch-digikey-digikey-adafruit/
Hi, I recently purchased 3 Wemos D1 mini pro with external antenna (which does not work because of an resistor that connects the onboard antenna to the system). These boards have the CH9102F chip. Linux and MacOS don’t recognize the chip. I downloaded the driver software from WCH and compiled it. In the description it says the cdc-acm driver has to be unloaded (rmmod). Then I see /dev/ttyCH343USB0. esptool.py does not recognize this driver and these boards are until now useless. So that is bit of a bummer. I also tried to load the CP2104 driver, but still no success.… Read more »
It’s possible that esptool cannot configure the non-conventional baud rate. You could try to download bootterm (https://github.com/wtarreau/bootterm), compile it and try to detect the device (bt -l), then try to connect to it (bt -b 74880 /dev/ttyCH343USB0) and see if it manages to connect at this speed (Ctrl-right bracket to close).
Hi Willy,
esptool does not recognize /dev/ttyCH434USB at all. That must be in the code somewhere.
I’ll try bootterm. Thanks for letting me know.
bt -l
port | age (sec) | device | driver | description
——+————+————+——————+———————-
* 0 | 203 | ttyCH343USB0 | usb_ch343 |
bt discovers the driver.
OK so the problem really is in esptool. It’s possible that it’s having issues with the /dev name. Just place a link like ttyUSB1 pointing to it, just in case. Otherwise maybe it’s failing on a specific ioctl that fails on this driver.
Hi Frank,
I also purchased a bunch of Wemos D1 mini pro with CH9102F. After adding adding Vendor and product ID to my udev rules (ATTRS{idVendor}==”1a86″, ATTRS{idProduct}==”55d4″) in Kubuntu 21.04 a serial Port (ttyACM) was available. Programming under Arduino did not work and the oscilloscope showed that the GPIO0 pin is not pulled properly to ground. A workaround is to connect it yourself to ground and so it is possible to program the chips.
Hi weigu,
thanks for finding that out. I am going to try to flash to wemos with your findings.
Cheers,
Frank
Hi weigu, I finally got it working. Found your webpage as well: http://weigu.lu/microcontroller/tips_tricks/esp8266_tips_tricks/. For some reason, the board does not go into flash mode automatically. I have to short GPIO0 to Ground. If I disconnect GPIO0 from ground, it ends flash mode. esptool.py --port /dev/ttyACM0 --baud 921600 --chip esp8266 flash_id esptool.py v3.1 Serial port /dev/ttyACM0 Connecting.... Chip is ESP8266EX Features: WiFi Crystal is 26MHz MAC: 84:f3:eb:3b:f0:3a Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Manufacturer: ef Device: 4018 Detected flash size: 16MB Hard resetting via RTS pin... 1234567891011121314151617 esptool.py --port /dev/ttyACM0 --baud 921600 --chip esp8266 flash_id esptool.py… Read more »
Hi Frank,
I think I found the culprit. They soldered a dual transistor SOT363 from LRC (marking 12) with a 22k resistor between emitter and base and a 22k resistor to the base. The original UMH3N (marking H3) have only a 4.7k to the base. These transistors are needed to tie down GPIO0 to GND.
Greetings Guy
It’s even possible that it’s an N-FET instead of an NPN, with a higher gate threshod voltage that is never reached with such a resistor configuration.