Is using the CH340G on a commercial product a horrible idea? [on hold]using usb serial converter as VDIP? arduinoUploading Program to Arduino Using FTDI Cable or ProgrammerTransmission (TX) halts using FTDI 232RL with ATmega328-PUEvent using FTD2XX_NET.dllNAND Flash reader using FTDIApplying USB to UART and RS-485 to UART to the single MCU UART portUsing cheap RF module encoding with UART in a commercial productRequirements for Integrating Thunderbolt 3 Into ProductProgramming microcontroller using UARTHow can I center a servo using the FT311D?
So a part of my house disappeared... But not because of a chunk resetting
Use 1 9 6 2 in this order to make 75
Why is the length of the Kelvin unit of temperature equal to that of the Celsius unit?
Converting from CMYK to RGB (to work with it), then back to CMYK
Is there a DSLR/mirorless camera with minimal options like a classic, simple SLR?
What would be the way to say "just saying" in German? (Not the literal translation)
How to avoid typing 'git' at the begining of every Git command
How was the airlock installed on the Space Shuttle mid deck?
Remove border lines of SRTM tiles rendered as hillshade
The origin of the Russian proverb about two hares
Assigning function to function pointer, const argument correctness?
bash vs. zsh: What are the practical differences?
Proving that a Russian cryptographic standard is too structured
Is Dumbledore a human lie detector?
Is Lambda Calculus purely syntactic?
Wizard clothing for warm weather
How can one's career as a reviewer be ended?
What are the unintended or dangerous consequences of allowing spells that target and damage creatures to also target and damage objects?
What is the reason for setting flaps 1 on the ground at high temperatures?
Does the Nuka-Cola bottler actually generate nuka cola?
noalign caused by multirow and colors
I've been given a project I can't complete, what should I do?
Make Gimbap cutter
Tikz-cd diagram arrow passing under a node - not crossing it
Is using the CH340G on a commercial product a horrible idea? [on hold]
using usb serial converter as VDIP? arduinoUploading Program to Arduino Using FTDI Cable or ProgrammerTransmission (TX) halts using FTDI 232RL with ATmega328-PUEvent using FTD2XX_NET.dllNAND Flash reader using FTDIApplying USB to UART and RS-485 to UART to the single MCU UART portUsing cheap RF module encoding with UART in a commercial productRequirements for Integrating Thunderbolt 3 Into ProductProgramming microcontroller using UARTHow can I center a servo using the FT311D?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
$begingroup$
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.
usb uart interface ftdi
asked May 26 at 21:31
willem.hillwillem.hill
234110
$endgroup$
put on hold as off-topic by RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking recommendations for specific products or places to purchase them are off-topic as they are rarely useful to others and quickly obsolete. Instead, describe your situation and the specific problem you're trying to solve." – RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover
add a comment |
$begingroup$
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.
usb uart interface ftdi
asked May 26 at 21:31
willem.hillwillem.hill
234110
$endgroup$
put on hold as off-topic by RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking recommendations for specific products or places to purchase them are off-topic as they are rarely useful to others and quickly obsolete. Instead, describe your situation and the specific problem you're trying to solve." – RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover
2
$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 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 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 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 at 11:52
add a comment |
$begingroup$
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.
usb uart interface ftdi
asked May 26 at 21:31
willem.hillwillem.hill
234110
$endgroup$
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.
usb uart interface ftdi
usb uart interface ftdi
asked May 26 at 21:31
willem.hillwillem.hill
234110
asked May 26 at 21:31
willem.hillwillem.hill
234110
asked May 26 at 21:31
willem.hillwillem.hill
234110
asked May 26 at 21:31
willem.hillwillem.hill
234110
asked May 26 at 21:31
willem.hillwillem.hill
234110
234110
put on hold as off-topic by RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking recommendations for specific products or places to purchase them are off-topic as they are rarely useful to others and quickly obsolete. Instead, describe your situation and the specific problem you're trying to solve." – RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover
put on hold as off-topic by RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover 2 days ago
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking recommendations for specific products or places to purchase them are off-topic as they are rarely useful to others and quickly obsolete. Instead, describe your situation and the specific problem you're trying to solve." – RoyC, Warren Hill, laptop2d, TimWescott, DoxyLover
2
$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 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 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 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 at 11:52
add a comment |
2
$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 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 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 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 at 11:52
2
2
$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 at 21:39
$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 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 at 1:09
$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 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 at 11:51
$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 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 at 11:52
$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 at 11:52
add a comment |
4 Answers
4
active
oldest
votes
$begingroup$
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.
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
$endgroup$
add a comment |
$begingroup$
There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
$endgroup$
add a comment |
$begingroup$
Generelly, 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 targetting.
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 200kbps 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 neccesary 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.
answered May 29 at 6:16
antipatternantipattern
1213
$endgroup$
add a comment |
$begingroup$
In order for your product to be field programmable / flash
cable 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%.
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
$endgroup$
add a comment |
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
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.
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
$endgroup$
add a comment |
$begingroup$
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.
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
$endgroup$
add a comment |
$begingroup$
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.
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
$endgroup$
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.
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
answered May 26 at 22:19
duskwuffduskwuff
18.9k33057
18.9k33057
add a comment |
add a comment |
$begingroup$
There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
$endgroup$
add a comment |
$begingroup$
There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
$endgroup$
add a comment |
$begingroup$
There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
$endgroup$
There is an Apple supplied driver for the CH340 included the recent versions of MacOS. "AppleUSBCHCOM".
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
edited May 27 at 15:57
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
answered May 26 at 23:04
Kevin WhiteKevin White
13.8k11625
13.8k11625
add a comment |
add a comment |
$begingroup$
Generelly, 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 targetting.
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 200kbps 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 neccesary 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.
answered May 29 at 6:16
antipatternantipattern
1213
$endgroup$
add a comment |
$begingroup$
Generelly, 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 targetting.
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 200kbps 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 neccesary 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.
answered May 29 at 6:16
antipatternantipattern
1213
$endgroup$
add a comment |
$begingroup$
Generelly, 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 targetting.
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 200kbps 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 neccesary 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.
answered May 29 at 6:16
antipatternantipattern
1213
$endgroup$
Generelly, 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 targetting.
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 200kbps 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 neccesary 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.
answered May 29 at 6:16
antipatternantipattern
1213
edited May 29 at 8:04
answered May 29 at 6:16
antipatternantipattern
1213
answered May 29 at 6:16
antipatternantipattern
1213
answered May 29 at 6:16
antipatternantipattern
1213
1213
add a comment |
add a comment |
$begingroup$
In order for your product to be field programmable / flashcable 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%.
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
$endgroup$
add a comment |
$begingroup$
In order for your product to be field programmable / flashcable 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%.
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
$endgroup$
add a comment |
$begingroup$
In order for your product to be field programmable / flashcable 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%.
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
$endgroup$
In order for your product to be field programmable / flashcable 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%.
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
edited May 27 at 10:03
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
answered May 27 at 9:58
Chetan BhargavaChetan Bhargava
4,26352137
4,26352137
add a comment |
add a comment |
2
$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 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 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 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 at 11:52