CH340 tester using a ATmega32u4?

[gmc]

I'm looking to build something like this for a friend so has loads of CH340G lying around. Some are faulty, some work.

Project Goal:  Connect a CH340G chip into a SOP16 to DIP adapter (So you don't have to solder them in only to find out they are faulty) and then test using a Atmega32u4 (Which supports usb host)
I want to have this as a standalone setup and not having to use the PC to test. (I know I can connect the CH340 up to the PC and short tx/rx lines to check data sent/recevied but am looking for something easier to use from the users perspective)

I want to use a Arduino Pro Micro which has a 32u4 which I'll connect up to the CH340 D+ / D-, then on the tx/tx output I connect that back to the Arduino.

Arduino code will then test communications by sending data via its usb host to the CH340, and will then read the data back in via tx/rx and toggle pass/fail status LED's on the Arduino

First off does this sound feasible? 

On the Arduino I will need to upload the code and then from USB D+/D- wire a connector to the CH340 (As the USB pins are available on the pinouts)

[magic]

ATmega32U4 doesn't support running its USB peripheral in host mode, but higher end AT90USB.... devices do.
Maybe some of the bitbanged USB implementations support host, but I don't know.

I'm a computer guy so I would make a board with a socket for CH340G, RX/TX loopback and a USB connector to test it with any PC...

[gmc]

Thanks, for some reason I could have sworn the 32u4 supported host mode but you are right. It doesn't.

I will have to look at one of the AT90USB devices. This might turn out to how to over engineer something you can do on the PC in 5 mins

[magic]

I have actually made such a board for my PL2303SA from a dodgy source (good luck finding them at legit distributors).
Except I didn't even solder the SOIC socket into it, but an ordinary DIP8 socket into which I plugged the SOIC adapter.

I think LUFA framework has drivers for USB host mode, perhaps even for communicating with CDC serial devices. But CH340 probably isn't CDC and probably has no LUFA driver, so that part you would need to write yourself regardless.

[gmc]

Might just order a at90usb and start messing around. Haven't used the lufa framework before but sounds like a interesting challenge.

[Nominal Animal]

You could use a Teensy 4.0 for this.  It has a second, USB Host -capable port on pads (D+ and D-) on the bottom side.  Use Teensyduino, the Teensy add-on to the Arduino environment, and the USBHost_t36 library for USB Host support; it includes USB Serial support.

I recommend you keep the original USB micro connector for the power supply, so that you don't need to cut any traces on the Teensy (VUSB-VIN on the back side).  This way, without cutting the trace, when connected to a host computer, the host will power the Teensy and the CH340 tester via USB; and when working standalone, you just connect an USB power bank to the Teensy USB connector.

There is a discussion forum dedicated for Teensy development at https://forum.pjrc.com/.


The CH340 has had Linux drivers since 2007 or so; see drivers/usb/serial/ch341.c.

These chips are way less scary to program/control than one might believe.  First, see the ch341_control_out() and ch340_control_in() functions.  (The usb/core/message.c:usb_control_msg() function constructs and sends one USB control message to the device, but the ch341_control_out() determines its contents.  So, it is just a matter of sending and receiving USB control messages to configure the CH340 –– and you can look up the necessary message data from the above-linked drivers/usb/serial/ch341.c file from the Linux kernel –– to configure the chip.)

Add an EC11 or similar encoder with a button, maybe a small OLED display, wire up a socket for the adapter, add a capacitor for the 5V USB line provided to the CH340 chip, maybe some Schottky diodes and current limiting resistors in case the chip is placed the wrong way on the adapter, and the rest should be software, methinks.

[magic]

Now that I think about it, some SBC like R-pi could be a very lazy option. Drivers for CH340 included in Linux.
Bonus for writing the software in Python

[gmc]

Great idea - I didn't think about the teensy. My go to has always been an arduino but I think this would work. 

As a extra project, it should also work with the rbp

[Nominal Animal]

NanoPi NEO (Wiki) would be one way to go via the SBC route.  Small, cheap, and exposes both USB and UARTs (including CTS and RTS, for hardware handshaking) on easily accessible pins, which are supported in Linux.  Essentially, connect the CH340 adapter to the correct pins on the NanoPi NEO, set up udev rules to give the dedicated user access to the USB port and UARTs (TTYs on the Linux side), and you can easily do everything in Python.

All signals are 3.3V logic level, and includes I2C, so you could even connect a small I2C OLED display. I suspect you might have to write the suitable "driver" in Python –– control logic, really ––, unless you use one of the existing ones, like this one.

[gmc]

Thanks guys. So many options.

Think Ill go the pi route as this looks the quickest  That NanoPi looks great and as it exposes the pins even better. Was looking at the Pi Zero I had lying around but then it doesn't expose the pins so need some hacking.

Putting a python script together should be easy enough.

[Nominal Animal]

Was looking at the Pi Zero I had lying around but then it doesn't expose the pins so need some hacking.

You'd need to cut off a Micro USB cable, so you could connect it to the Pi Zero micro-USB connector, and the leads to the socket for the adapter.  Pins 8 and 10 are UART TX and RX (which you need to connect to corresponding RX and TX on the CH340), but I don't know if any of the GPIO pins can be used for hardware handshaking (RTS, CTS).  They certainly could be used from Python as plain GPIOs, but synchronizing them separately with the UART is a bit of a pain.

(I happened to buy a NanoPi NEO from eBay back when they were ubiquitous and laughably cheap.  I paid less than 20€ for mine, shipped.)

Full disclosure: I don't help with Raspberry Pi stuff, because the Pi Foundation folks were mean to me and other open source developers (those licensing stuff under the GPL, specifically).  Call me childish, but I prefer other Linux SBCs.

[magic]

You'd need to cut off a Micro USB cable, so you could connect it to the Pi Zero micro-USB connector, and the leads to the socket for the adapter.  Pins 8 and 10 are UART TX and RX (which you need to connect to corresponding RX and TX on the CH340)

I don't help with Raspberry Pi stuff

BTW, for a truly professional embedded computing solution, like those used in ATMs for example, you should be using a serious business hardware running a professional operating system which doesn't piggyback on the efforts of volunteer open source developers, such as MicrosoftⓇ Windows™.

Cut a hole in your PC to mount the SOIC socket.
Connect the CH340 under test to one of the internal USB headers on the motherboard.
Connect a second UART to another USB header and connect it with the CH340 socket.
Write your software in C# .NET to blink the Caps Lock LED when a good chip is inserted.

Here it is - your single box embedded solution

[Nominal Animal]

You'd need to cut off a Micro USB cable, so you could connect it to the Pi Zero micro-USB connector, and the leads to the socket for the adapter.  Pins 8 and 10 are UART TX and RX (which you need to connect to corresponding RX and TX on the CH340)

I don't help with Raspberry Pi stuff

Hey, at least I'm honest about my hangups.

BTW, for a truly professional embedded computing solution, like those used in ATMs for example, you should be using a serious business hardware running a professional operating system which doesn't piggyback on the efforts of volunteer open source developers, such as MicrosoftⓇ Windows™.

Ah, a professional enterprise solution.  Costs twice as much, no guarantees; but nobody ever gets fired or punished for purchasing these.  They're buggy, and lack half the things the users actually need, because they've been pushed to a future upgrade (even though prominently displayed on the brochure).