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.

  • 3
    \$\begingroup\$ Could you just provide a separate cable that can be purchased if the user actually wants to reflash it? Or is reflashing essential to the use of the product? \$\endgroup\$ – DKNguyen May 26 '19 at 21:39
  • \$\begingroup\$ Reflashing is essential to the use of the product, as it may be used in many different scenarios, and must be completely reconfigurable by the customer at a future date for different applications. \$\endgroup\$ – willem.hill May 27 '19 at 1:09
  • \$\begingroup\$ Does one customer usually have only one of the devices, or many? If there are many decices per customer, Chetan Bhargava may be a good option: make the programming interface separate from the device itself. \$\endgroup\$ – jcaron May 27 '19 at 11:51
  • \$\begingroup\$ An example of a product which used a CH340 and had to switch to a CP2104 to resolve issues: github.com/sqfmi/badgy#rev-2b \$\endgroup\$ – jcaron May 27 '19 at 11:52
  • \$\begingroup\$ Better question is can you buy a CH340 chip? There were no US suppliers that carrry it last time I checked. \$\endgroup\$ – CrossRoads Jun 11 '19 at 15:00

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.

|improve this answer|||||
  • \$\begingroup\$ 16U2 is a common option used on the Arduino Uno and Mega, which are OS X compatible - even older versions. \$\endgroup\$ – Greenonline Jun 11 '19 at 14:30
  • 1
    \$\begingroup\$ @Greenonline Same family as the 32U4 I mentioned, just a smaller version. \$\endgroup\$ – duskwuff -inactive- Jun 11 '19 at 19:32

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

|improve this answer|||||

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.


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.


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.


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


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.

|improve this answer|||||

In order for your product to be field programmable / flashenter image description herecable is to use a common header pin out. Arduino pinout is pretty common. there is no need to embed a USB to serial converter if your updates are not weekly. For a field setup I would increase the cost of field programming equipment rather than field program-ability into

No need to embed a serial converter if you need to flash less often.

Some common (and low cost) USB to serial converters are based upon following chip-sets.

FTDI - Windows and Linux drivers but the drivers can brick your cable - avoid
CH340 - Windows and Linux drivers
PL2303 - Windows and Linux driver

The drivers are easily available for Windows and Linux platform. I can't say much about apple as I can't afford an apple laptop.

I would rather leave the USB-Serial out of my project if the probability to program in field is < 50%.

|improve this answer|||||

Not the answer you're looking for? Browse other questions tagged or ask your own question.