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

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?

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.

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.