Is using the CH340G on a commercial product a horrible idea?

Question

I'm developing a niche product that will be produced at a fairly low volume (low hundreds). I'm using an Atmega uC, and one of the requirements is the ability to be field-flashable by the user. My plan is to use the Arduino bootloader with a USB-to-UART IC (lazy, I know, but at this volume it is probably the best option).

There are many choices. My prototype board right now is using the FTDI FT232RL, but that is too expensive for production, as the price point for the whole board is around $20.

ICs I've considered include:

• CH340G
  • Cheapest option, but what's the status of signed drivers for OSX? I can't determine whether this will be completely plug and play. Does anyone know what the status of this is?
• CP2102
  • Robust, no worries about signed drivers etc. But it is more expensive.
• MCP2200
  • Also robust, no worries about signed drivers. How do I choose this versus the CP2102? They are nearly the same price.

Are there any other "gotchas" with the above choices other than signed drivers? I don't want to force the user to install unsigned drivers/add a potentially painful process to the re-flashing procedure, but I also don't really want to add $2 to the BOM cost just for user-flashability.

Any general guidance/advice would be useful. Thanks.

Answer 1

The simplest option, and the one I'd recommend here, would be to use a microcontroller which supports USB natively and can be programmed with a USB DFU (Device Firmware Update) bootloader. One example of such a microcontroller is the ATmega32U4, as seen on the Arduino Leonardo; another is the ST STM32F103. Even if these microcontrollers are a bit more expensive than the one you would have used otherwise, the increase in cost is probably less than the cost of a discrete USB UART interface. Using a single part will also reduce the overall size and power consumption of your device.

Answer 2

There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".

Answer 3

Generally, if you give your customers the ability to flash your device, you want them not to brick it.

Thus, the main priority providing is a robust and safe connection to the host device. In my experience all of the chips work rather well in the urban and laboratory settings which I assume you are targeting.

Consider also the time it would require to get the component to work right - your production count is in the low hundreds, and you add $2 to each. Is that "loss" worth more than your (or the developer's) time? A well-documented chip might be actually a better choice, even if it costs more.

CH340

Yes, it is really a bad Idea, at least if you want Plug-And-Play. For me on Win 8.1, I needed to manually install the driver (CH340SER.exe) which I had to download from the (Chinese) manufacturer's website which had (at that time) no English translation.

It was hosted in China, which might be an issue for security-minded individuals and those bound by organizational and/or political rules. Also it was outranked as a search result by a lot of dubious "Free" driver download sites.

If this was any serious equipment (opposed to "just" an Arduino), that'd be raising my eyebrows to the ceiling. Manually installing might also very annoying if your customers don't have dedicated Equipment for flashing.

Otherwise, this chip worked as expected.

CP2102

Not much to say about, worked out of the box and did not bring up any issues. Would probably be my choice for an average design.

FTDI

I have this one on an standalone USB-Serial converter board and it performs well. As you wrote, it is rather expensive, but I believe it might be a better choice in rough environments (for example corroded contacts on connectors, also EMI). Might give you a warm fuzzy feeling because you support the original developers.

Other ideas

ISP

As per @Chetan Bhargava's answer, an option would be to have an connector for the SPI and then use a standalone USB-Serial converter.

This also requires you to provide a reliable and safe to use connector for the ISP to attach to. Obviously you can go cheap with pin headers here, but if you want to do it right (and/or don't trust your customers enough), then this connector might be more costly than the additional chip and a stock USB connector. Serial connections are furiously hard to debug if they don't work, opposed to USB where the customer will at least get notified that the USB device is not working.

If you bundle a standalone converter with your board, you will have to pay the price for the converter board too. I'd assume this would not be cheaper than to integrate the chip. This could work if each customer owns many of your boards, so the converter could get reused, or if you can just shove the costs of acquiring the programmer to the customer side.

If this option is a possibility, at this point, there's also Atmel's very own AVRISP which is a good choice here instead of the plain USB-to-Serial, though a bit outdated. I think it caps out at about 100 or 200 kbps where modern USB-Serial converters go into the megabit range. But it is very robust in regard to (mis-)usage.

Another good option could be a TC2030 connector. It only requires pads on the PCB to work with, but requires some expertise (you have to hold it on the spot until the programming is finished).

Communication interfaces

Modern microcontrollers also come with a number of other communication interfaces (Ethernet, WiFi, Bluetooth) and usually can be flashed using these. An example would be the ESP32 which comes at a cost of about 6 USD and is a SoC with all components necessary for a wifi connection. Also it is Arduino-compatible (you can even use the IDE) and has a very thorough example set, including an WiFi OTA bootloader. You would only need an ISP for the initial deployment of the bootloader.

If - as it sounds in your question - your project is mostly finished, this is probably not an option anymore.