L'utilisation du CH340G sur un produit commercial est-elle une horrible idée? [fermé]

12

Je développe un produit de niche qui sera produit à un volume assez faible (des centaines faibles). J'utilise un Atmega uC, et l'une des exigences est la capacité d'être flashable sur le terrain par l'utilisateur. Mon plan est d'utiliser le chargeur de démarrage Arduino avec un IC USB-UART (paresseux, je sais, mais à ce volume, c'est probablement la meilleure option).

Les choix sont nombreux. Mon prototype de carte utilise actuellement le FTDI FT232RL, mais c'est trop cher pour la production, car le prix pour la carte entière est d'environ 20 $.

Les CI que j'ai envisagés incluent:

  • CH340G
    • Option la moins chère, mais quel est le statut des pilotes signés pour OSX? Je ne peux pas déterminer si ce sera complètement plug and play. Quelqu'un sait-il quel est le statut de cela?
  • CP2102
    • Robuste, pas de soucis pour les pilotes signés, etc. Mais c'est plus cher.
  • MCP2200
    • Aussi robuste, pas de soucis pour les pilotes signés. Comment choisir cela par rapport au CP2102? Ils sont presque au même prix.

Y a-t-il d'autres "pièges" avec les choix ci-dessus autres que des pilotes signés? Je ne veux pas forcer l'utilisateur à installer des pilotes non signés / ajouter un processus potentiellement pénible à la procédure de re-clignotement, mais je ne veux pas vraiment ajouter 2 $ au coût de la nomenclature juste pour la capacité de flashabilité de l'utilisateur.

Toute orientation / conseil général serait utile. Merci.

willem.hill
la source
3
Pourriez-vous simplement fournir un câble séparé qui peut être acheté si l'utilisateur souhaite réellement le reflasher? Ou le reflashing est-il essentiel à l'utilisation du produit?
DKNguyen
Le reflashing est essentiel à l'utilisation du produit, car il peut être utilisé dans de nombreux scénarios différents et doit être complètement reconfigurable par le client à une date ultérieure pour différentes applications.
willem.hill
Un client possède-t-il généralement un seul ou plusieurs appareils? S'il y a de nombreuses décisions par client, Chetan Bhargava peut être une bonne option: séparez l'interface de programmation de l'appareil lui-même.
jcaron
Un exemple de produit qui utilisait un CH340 et devait passer à un CP2104 pour résoudre les problèmes: github.com/sqfmi/badgy#rev-2b
jcaron
Une meilleure question est de savoir si vous pouvez acheter une puce CH340? Il n'y avait aucun fournisseur américain qui l'ait effectué la dernière fois que j'ai vérifié.
CrossRoads du

Réponses:

26

L'option la plus simple, et celle que je recommanderais ici, serait d'utiliser un microcontrôleur qui prend en charge USB nativement et peut être programmé avec un chargeur de démarrage USB DFU (Device Firmware Update). Un exemple d'un tel microcontrôleur est l'ATmega32U4, comme on le voit sur l'Arduino Leonardo; un autre est le ST STM32F103. Même si ces microcontrôleurs sont un peu plus chers que celui que vous auriez utilisé autrement, l'augmentation du coût est probablement inférieure au coût d'une interface USB UART discrète. L'utilisation d'une seule pièce réduira également la taille globale et la consommation d'énergie de votre appareil.

duskwuff -inactif-
la source
16U2 est une option courante utilisée sur les Arduino Uno et Mega, qui sont compatibles OS X - même les versions plus anciennes.
Greenonline
1
@Greenonline Même famille que le 32U4 que j'ai mentionné, juste une version plus petite.
duskwuff -inactive-
8

Il existe un pilote fourni par Apple pour le CH340, y compris les versions récentes de MacOS. "AppleUSBCHCOM".

Kevin White
la source
2

Généralement, si vous donnez à vos clients la possibilité de flasher votre appareil, vous voulez qu'ils ne le briquent pas.

Ainsi, la principale priorité apportée est une connexion robuste et sûre au périphérique hôte. D'après mon expérience, toutes les puces fonctionnent plutôt bien dans les environnements urbains et de laboratoire que je suppose que vous ciblez.

Considérez également le temps qu'il faudrait pour que le composant fonctionne correctement - votre décompte de production est dans les centaines faibles et vous ajoutez 2 $ à chacun. Cette «perte» vaut-elle plus que votre temps (ou celui du développeur)? Une puce bien documentée pourrait être en fait un meilleur choix, même si elle coûte plus cher.

CH340

Oui, c'est vraiment une mauvaise idée, du moins si vous voulez Plug-and-Play. Pour moi sur Win 8.1, j'avais besoin d'installer manuellement le pilote ( CH340SER.exe) que je devais télécharger sur le site Web du fabricant (chinois) qui n'avait (à l'époque) aucune traduction en anglais.

Il a été organisé en Chine, ce qui pourrait être un problème pour les individus soucieux de la sécurité et ceux liés par des règles organisationnelles et / ou politiques. En outre, il a été devancé en tant que résultat de recherche par de nombreux sites de téléchargement de pilotes "gratuits" douteux.

S'il s'agissait d'un équipement sérieux (opposé à "juste" un Arduino), ce serait lever les sourcils au plafond. L'installation manuelle peut également être très gênante si vos clients n'ont pas d'équipement dédié au flashage.

Sinon, cette puce a fonctionné comme prévu.

CP2102

Pas grand chose à dire, a fonctionné hors de la boîte et n'a soulevé aucun problème. Serait probablement mon choix pour un design moyen.

FTDI

J'ai celui-ci sur une carte convertisseur USB-série autonome et il fonctionne bien. Comme vous l'avez écrit, c'est assez cher, mais je pense que cela pourrait être un meilleur choix dans des environnements difficiles (par exemple des contacts corrodés sur des connecteurs, également EMI). Pourrait vous donner un sentiment flou chaleureux parce que vous soutenez les développeurs originaux.

Autres idées

FAI

Selon la réponse de @Chetan Bhargava, une option serait d'avoir un connecteur pour le SPI, puis d'utiliser un convertisseur USB-série autonome.

Cela vous oblige également à fournir un connecteur fiable et sûr à utiliser auquel le FAI peut se connecter. Évidemment, vous pouvez vous rendre à bon marché avec des en-têtes de broches ici, mais si vous voulez le faire correctement (et / ou ne faites pas suffisamment confiance à vos clients ), ce connecteur pourrait être plus coûteux que la puce supplémentaire et un connecteur USB d'origine. Les connexions série sont furieusement difficiles à déboguer si elles ne fonctionnent pas, contrairement à l'USB où le client sera au moins informé que le périphérique USB ne fonctionne pas.

Si vous regroupez un convertisseur autonome avec votre carte, vous devrez également payer le prix de la carte du convertisseur. Je suppose que ce ne serait pas moins cher que d'intégrer la puce. Cela pourrait fonctionner si chaque client possède plusieurs de vos cartes, de sorte que le convertisseur pourrait être réutilisé, ou si vous pouvez simplement pousser les coûts d'acquisition du programmateur du côté client.

Si cette option est possible, à ce stade, il y a aussi le propre AVRISP d'Atmel qui est un bon choix ici au lieu du simple USB-à-série, bien qu'un peu dépassé. Je pense qu'il plafonne à environ 100 ou 200 kbps où les convertisseurs USB-série modernes vont dans la gamme mégabits. Mais il est très robuste en matière de (mauvaise) utilisation.

Une autre bonne option pourrait être un connecteur TC2030. Il ne nécessite que des pads sur le PCB pour fonctionner, mais nécessite une certaine expertise (vous devez le tenir sur place jusqu'à la fin de la programmation).

Interfaces de communication

Les microcontrôleurs modernes sont également livrés avec un certain nombre d'autres interfaces de communication (Ethernet, WiFi, Bluetooth) et peuvent généralement être flashées à l'aide de celles-ci. Un exemple serait l' ESP32 qui coûte environ 6 USD et est un SoC avec tous les composants nécessaires pour une connexion wifi. Il est également compatible Arduino (vous pouvez même utiliser l'IDE) et dispose d'un ensemble d'exemples très complet, y compris un chargeur de démarrage WiFi OTA. Vous n'auriez besoin que d'un FAI pour le déploiement initial du chargeur de démarrage.

Si - comme cela semble dans votre question - votre projet est presque terminé, ce n'est probablement plus une option.

antipattern
la source
-2

Pour que votre produit soit programmable sur le terrain / le entrez la description de l'image icicâble flash doit utiliser une broche d'en-tête commune. Le brochage Arduino est assez courant. il n'est pas nécessaire d'intégrer un convertisseur USB vers série si vos mises à jour ne sont pas hebdomadaires. Pour une installation sur le terrain, j'augmenterais le coût de l'équipement de programmation sur le terrain plutôt que la


Pas besoin d'intégrer un convertisseur série si vous devez flasher moins souvent.

Certains convertisseurs USB vers série courants (et à faible coût) sont basés sur les jeux de puces suivants.

FTDI - Pilotes Windows et Linux mais les pilotes peuvent
endommager votre câble - éviter CH340 - Pilotes Windows et Linux
PL2303 - Pilote Windows et Linux

Les pilotes sont facilement disponibles pour les plates-formes Windows et Linux. Je ne peux pas en dire beaucoup sur Apple car je ne peux pas me permettre un ordinateur portable Apple.

Je préfère laisser l'USB-Serial hors de mon projet si la probabilité de programmer sur le terrain est <50%.

Chetan Bhargava
la source