Pourquoi FTDI et non AVR avec contrôleur USB intégré?


8

J'ai fait un programme simple en Visual C # qui communique avec AVR via la puce FT232RL.

PC <-> FTDI <-> MCU.

J'utilise FTD2XX_NET.dll pour un accès direct au périphérique USB.

Je me demande, quelle est la différence entre une paire de FTDI-AVR et un seul AVR avec contrôleur USB intégré? Je pense qu'il doit y avoir une certaine différence dans la vitesse de communication. Quoi d'autre est différent?


2
Avec le FTDI, le programmeur de l'AVR n'a pas à implémenter une pile USB mais plutôt juste un support UART. Il y a beaucoup d'autres différences dont je ne sais pas, je suis sûr, c'est pourquoi je ne réponds pas mais je commente simplement
Funkyguy

1
Les FTDI sont également livrés avec des pilotes signés pour la plupart des plates-formes et des VID et PID codés en dur valides, vous n'avez donc pas à payer pour 65536 adresses lorsque vous en avez besoin d'une seule.
venny

Merci pour les commentaires. Autre différence de performance? Quelle est la meilleure solution pour la communication PC et MCU? Pour être honnête, le FTDI est BEAUCOUP plus facile avec les contrôleurs USB intégrés.
MrBit

Dans le logiciel PC avec voie FTDI, les fonctions difficiles sont très faibles. Et je ne sais pas si un effort avec un seul AVR en vaut la peine
MrBit

1
FTDI est une série stupide. Un MCU peut prétraiter, activer des canaux latéraux, prendre en charge l'UMS, etc.
Ignacio Vazquez-Abrams

Réponses:


11

Il y a plusieurs raisons, mais elles sont, au moins pour la plupart des gens, assez niches.

Les raisons que je vois et que j'ai vécues

  • Le choix dans les AVR compatibles USB est assez limité, en particulier la famille TINY. Si, pour une raison quelconque, un AVR est nécessaire sans combinaison USB et d'autres périphériques, c'est une option facile. Un exemple qui me vient à l'esprit est celui des AVR compatibles PLL.
  • Même si le périphérique USB est implémenté dans le matériel, vous devez toujours mettre une pile USB dans le firmware. Cela prend beaucoup de ressources (par exemple, LUFA nécessite au moins 6 Ko de mémoire flash et 1,5 Ko de RAM pour une implémentation CDC complète, et c'est l'une des bibliothèques les plus légères)
  • Les interruptions USB et les événements de bus USB occupent des ressources qui peuvent perturber le micrologiciel critique. Par exemple: les mesures ADC à haute vitesse peuvent être très gâchées lorsqu'une tâche USB s'interrompt.
  • Toutes les implémentations de bibliothèques USB ne fonctionnent pas aussi bien avec tous les AVR compatibles USB. Par exemple: les chargeurs de démarrage USB utilisant LUFA ne fonctionnent pas avec les périphériques XMEGA.
  • FTDI utilise des pilotes signés qui s'installent automatiquement à l'aide de Windows Update, contrairement à de nombreuses bibliothèques USB, par exemple ASF et LUFA. Cela rend le déploiement auprès des utilisateurs finaux plus lourd.
  • Certaines implémentations ont des performances inférieures, par exemple le FT2232H est capable de relier un FIFO à USB à 8 Mo / s, ce qui est impossible à faire avec un AVR.
  • De nombreux projets n'ont pas un contrôle total sur le matériel et les logiciels, par exemple les imprimantes 3D ont des projets matériels et des projets de micrologiciel complètement séparés. Afin de maintenir le niveau d'interopérabilité le plus élevé possible, les fonctions USB et microcontrôleur sont séparées.

Cependant, avec les bibliothèques USB prêtes à l'emploi, le coût important des ponts USB FTDI (ils coûtent généralement plus cher que même les AVR très haut de gamme) et aucune pénalité de performance dans la plupart des applications, il est très difficile de justifier les puces FTDI de nos jours si vous avoir un contrôle total sur le matériel et le firmware.


2
Même si un projet est sur un microcontrôleur qui a intégré une interface USB et que le plan est de l'utiliser, cela vaut toujours la peine d'avoir un en-tête pour accéder aux broches UART, car vous pouvez obtenir trivialement une sortie de débogage utile à partir de cela tout en essayant d'obtenir l'USB code pour travailler.
Chris Stratton

4
Le commentaire de @ ChrisStratton met en évidence un autre problème: les périphériques USB sont plus difficiles à déboguer qu'un simple périphérique série UART. Il accélère donc le développement et supprime les inconnues pour laisser la fin USB des choses à la puce FDTI déboguée et fonctionnelle. Évidemment, l'économie change avec la quantité, mais pour une petite production avec une pression temporelle, la solution FDTI est généralement meilleure.
markrages

Wow, votre tl;drparagraphe a certainement été une fin surprise ... Vous avez mis au rebut des piles USB / série uniquement micrologicielles (bien qu'avec des points extrêmement valides), puis BAM ... "seul un idiot utiliserait FTDI". Hilarant. J'aime ça!
alex grey

@alexgray: Wow, vous parlez vraiment à l'extrême. Je ne pense pas que je parlais de trash quoi que ce soit; ce ne sont que les types typiques d'objectifs que les gens ont dans la conception de produits. J'ai traité des projets qui ont optimisé à peu près toutes les combinaisons de ces points. Pour les projets de loisir, il peut y avoir une approche Trump contre Sanders pour résoudre `` dois-je ou ne prends-je pas un pont FTDI RS-232? '', Mais dans la vraie ingénierie, vous devriez vraiment considérer objectivement tous les avantages et les inconvénients et arriver à un conclusion optimale.
user36129

4

Il y a des avantages à utiliser une puce USB séparée et à laisser l'AVR communiquer via son UART.

Une pile USB doit répondre à l'interrogation du PC hôte. Cela se produit au moins toutes les millisecondes. Cela signifie qu'il est encore plus difficile de garantir une réponse dure en temps réel aux événements, car le MCU pourrait être interrompu pour répondre au sondage USB des hôtes.

Lorsqu'il n'y a rien à communiquer ou que le MCU souhaite se concentrer pleinement sur une tâche en temps réel, il doit toujours répondre à certains événements d'interrogation USB de l'hôte, ou l'hôte `` perdra '' le périphérique. Il est donc difficile de l'ignorer. Une puce USB dédiée, comme un FTDI, décharge ces tâches de l'AVR.

Un petit problème est que la pile USB consommera une quantité raisonnable de mémoire flash et de RAM, donc la puce a besoin de plus de ressources qu'un simple AVR.

De plus, les deux parties peuvent être séparées sur deux cartes, donc l'USB n'est pas un coût fixe, mais peut être partagé entre plusieurs cartes.

D'un autre côté, le principal avantage d'utiliser un AVR avec un périphérique USB intégré et une pile USB est qu'il n'y a qu'une seule pièce à acheter et à assembler.

Je n'ai pas vérifié récemment, mais je pense que les nouvelles puces FTDI ont fourni un taux de transfert de données USB plus élevé que le USB de l'AVR. Cependant, les AVR UART étaient si lents qu'un AVR avec USB est un transfert plus rapide que la combinaison de FTDI (ou de toute interface USB) communiquant via l'UART de l'AVR en raison de la lenteur de l'AVR UART.

Edit: FTDI fait d'autres interfaces que UART. Par exemple SPI. Je n'ai aucune expérience de leur utilisation. Certains AVR prennent en charge le transfert SPI 9 (peut-être 12) mégabits. Le FTDI est le maître SPI, ce qui n'est pas idéal. Si l'AVR est en train de transmettre, cela peut être correct, car les FTDI ont des tampons, mais recevoir peut être «comme boire dans une lance à incendie». AFAIK, vous devrez travailler sur le PC hôte pour le faire fonctionner.

Le transfert le plus rapide pourrait être via une carte fille Ethernet de 100 Mbits, mais je n'ai pas vu de mesures de débit.

Je suis heureux d'utiliser d'autres microcontrôleurs que l'AVR. Donc, je pourrais utiliser quelque chose avec un UART rapide et un contrôleur DMA qui pourrait déplacer des caractères sans implication du processeur. Si c'est une approche utile, regardez peut-être le Arduin Due, ou le mbed, le ST mbed est appelé nucelo qui est à faible coût.


en ce qui concerne le taux de transfert AVR UART, oui c'est vraiment lent ... donc (pour résoudre ce problème) de quelle manière existe-t-il pour établir la communication entre les puces AVR et FTDI? Maintenant, je suis en 230,4kbps en mode
uart

@ user3829694 - Je ne sais pas ce que vous voulez dire. Vous demandez comment aller plus vite que 230,4kbps? Ou dites-vous que 230,4 kbps vous conviennent?
gbulmer

Je demande, si je veux plus de vitesse, que puis-je faire d'autre? Je pense que FT245 FIFO, il peut aller jusqu'à 1Mbps. J'essaie de faire des projets HID avec une "surveillance en temps réel" juste pour collecter des données de avr (avec capteurs, etc.) sous forme de PC. Mais avec UART même en vitesse maximale (230,4kbps) le taux de transfert du tampon entier (256byte) cela prend environ 9ms: 230,4kbit = 28,8kByte = 1 / 28,8 = 34,722us par octet * 256byte = 8.88ms / 256 octets, je pensais que cette fois, ce n'était pas bon pour la surveillance en temps réel
MrBit

si je veux rafraîchir mon formulaire tous les 10 à 100 ms (envoi-réception de données tous les 10 à 100 ms), il n'y a plus de temps pour AVR pour traiter les autres tâches.
MrBit

@ user3829694 - D'accord, vous voulez donc déplacer les données rapidement, avec peu de frais généraux.
gbulmer
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.