CH9102F – A replacement for CP2104 USB to UART bridge

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.

CH9102F vs CP2104The good news is that CH9102F and CP2104 have basically both the same pinout albeit with some small differences that may or may not matter depending on the application, and come in a 4x4mm 24-QFN package (4x4mm) meaning if you run out of CP2104 chips, CH9102F can be used as an alternative, and should be a drop-in replacement.

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.

CP210x vs CH340K vs CH9102

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

CP2104 Price September 2021The price is close to $4 per unit which does seem on the high side for a chip that is often found in $5 to $10 boards

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

CH9102F priceSeveral vendors offer CH9102 parts for between 5 and 6 CNY, or about 78 to 93 US cents. That’s a noticeable difference. I wanted to check CP2104 price on 1688, but I was out of “search allowance”, and asked to create an account and log in…

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…

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
25 Comments
oldest
newest
olin
olin
2 months ago

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.

Juanjo(@juanjo_sanchez)
2 months ago

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.

Captura.JPG
Jon Smirl
2 months ago

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.

willy
willy
2 months ago

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.

dgp
dgp
2 months ago

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

willy
willy
2 months ago

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!

Jon Smirl
2 months ago

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.

dgp
dgp
2 months ago

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

Willy
Willy
2 months ago

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.

RobBrownNZ
RobBrownNZ
2 months ago

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.

Hedda
Hedda
2 months ago

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.

zoobab
2 months ago

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.

Ivan Grokhotkov
Ivan Grokhotkov
2 months ago

FYI, the driver for macOS is not in a good state yet, see https://github.com/Xinyuan-LilyGO/LilyGo-T-Call-SIM800/issues/139.

Ciro Bruno
Ciro Bruno
13 days ago

That’s it, @Ivan Grokhotkov.

CH9102F really doesn’t work at all in Mac OS.

David
David
2 months ago

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/

Frank
Frank
2 months ago

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 »

Willy
Willy
2 months ago

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

Frank
Frank
2 months ago

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.

Frank
Frank
2 months ago

bt -l
 port | age (sec) | device   | driver      | description      
——+————+————+——————+———————-
 * 0 |    203 | ttyCH343USB0 | usb_ch343    |          

bt discovers the driver.

willy
willy
2 months ago

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.

weigu
2 months ago

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.

Wemos_D1_mini_pro_RESET_GPIO0_CG9102.png
Frank
Frank
1 month ago

Hi weigu,

thanks for finding that out. I am going to try to flash to wemos with your findings.

Cheers,

Frank

Frank
Frank
1 month ago

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 »

weigu
1 month ago

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

Willy
Willy
1 month ago

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.

Advertisement