CH340 USB to TTL Serial Adaptor (HCMODU0076)

Modules for interfacing including USB to serial and SD adaptors.
Post Reply
Site Admin
Posts: 748
Joined: Sun Aug 05, 2012 4:02 pm

CH340 USB to TTL Serial Adaptor (HCMODU0076)

Post by admin » Thu Feb 26, 2015 11:04 am



The CH340 USB to serial adaptor (HCMODU0076) makes use of the CH340 USB to serial IC to provide a low cost alternative to our popular FTDI based module. Although much cheaper this module doesn't lack in features or usability. Once you have installed the drivers the module will appear as a normal serial COM port on your computer making it compatible with most terminal programs and development environments such as the Arduino IDE.

The module includes a small switch which allows the voltage available at the VC (Supply output) pin to be switched between 3.3 and 5V. Data pins include TX, RX, CTS and DTR (needed for automatic reset when programming Arduino boards). These digital pins are at 5V TTL levels allowing them to be directly interfaced most 5V microcontrollers.

Please note: Driver support is currently for Microsoft Windows 32/64 bit only.


DTR....Data Terminal Ready
RXD....Serial in
TXD....Serial out
VC......3.3V or 5V Supply out selected via switch
CTS.....Clear To Send


Windows drivers:

MAC installation instructions

New code signed version confirmed to work with 10.12 Sierra

Older code signed version confirmed to work with El Capitan


Download the driver (you must be logged in to download)

Once downloaded, double-click the zip file to unzip it.

Run installer found in that folder.

If asked to restart, do not restart just yet.

Now restart your Mac.
You do not have the required permissions to view the files attached to this post.

Posts: 2
Joined: Wed Sep 09, 2015 2:36 pm

Re: CH340 USB to TTL Serial Adaptor (HCMODU0076)

Post by Robin2 » Wed Nov 01, 2017 7:47 pm

I bought 2 of these adapter recently and I discovered that I could not upload code to a breadboard Atmega 328P with one of them. (I only have one at the moment as the other was for a friend).

I had a useful phone discussion with Andrew yesterday at which time I thought the problem was that the adapter was failing to cause the Atmega 328 to reset when trying to upload code. On my adapter the DTR line is LOW by default and goes HIGH briefly when a program is to be uploaded. This seems to be the reverse of normal behaviour.

Later I came to the conclusion that the adapter was actually causing the 328 to reset and the problem was that it would not work properly at 57600 baud which is the upload rate used by the bootloader. The adapter works fine at 115200 baud and at 19200 baud.

After a lot of fiddling around I managed to compile a version of the Optiboot bootloader that uploads at 19200 baud and now I can upload with the CH340 as well as with an older USB-TTL cable that i have had for a few years and which works at 57600 baud.


Posts: 1
Joined: Tue Mar 27, 2018 3:09 pm

Re: CH340 USB to TTL Serial Adaptor (HCMODU0076)

Post by maxere » Mon Oct 15, 2018 2:36 pm

Just thought I would like to add some thoughts re latency.
I am at the moment trying to control a PC scope card designed for use with an ISA 8 bit data bus. So far I am able to activate the DTR line for use as an external signal. This operates for me as a read/write signal but has a 3 mSec latency so when reading or writing the port a software delay of 5 m Sec is needed before the port write can be sent. If the DTR is tested in a closed loop this functions ok.
Problem now is sending a data byte then the address byte. The Tx line also has a significant latency delay, so even though the two port writes have a register test to prevent overwriting before the out port command, the data and address writes also need an inter delay. Writing a single byte produces the correct data (@115baud). Putting the writes in a software loop causes all kinds of mis-firing so scoping the signals is near impossible. Introducing a 100uSec delay does not separate the writes so the latency must be greater. I wonder if the latency is similar to the DTR at 3 mSecs ?
I shall persevere until I can tie down the Tx latency delay I need between data & address bytes. Unless this work has been done already ???

Post Reply