Comment fonctionne une puce FTDI?

20

Quelqu'un m'a demandé l'autre jour comment fonctionne un USB FTDI vers UART série, et j'ai réalisé que je ne savais pas. J'ai regardé la fiche technique du FT232R et le schéma fonctionnel ne m'a pas vraiment aidé. Quelqu'un peut-il m'expliquer ou me lier à une bonne explication?

usb uart ftdi

— aloishis89
source

3

Plus d'explication qu'elle n'implémente le côté périphérique d'un périphérique USB CDC? en.wikipedia.org/wiki/USB_communications_device_class

— kenny

1

@kenny, en fait, ce n'est pas le cas. Il utilise un profil propriétaire, c'est pourquoi vous devez installer des pilotes pour l'utiliser (au moins sous Windows).

— avakar

2

@avakar, il utilise des pilotes sur tous les OS, certains viennent juste préchargés.

— Kortuk

15

Les puces FTDI implémentent la pile de protocoles USB. La responsabilité de ce matériel est de dire à votre PC de quoi il s'agit (en utilisant des informations d'identification) afin que votre ordinateur puisse charger le bon pilote pour lui, et également de gérer les transactions de données avec le PC qui se trouve après - recherchez les points de terminaison USB pour une meilleure explication de ces processus.

Une fois ces pilotes chargés, cela spécifierait un jeu de commandes que votre PC peut utiliser pour interroger la puce. Ce matériel prend en charge un côté de l'équation (communication avec votre PC). L'autre côté serait un matériel dédié pour gérer le protocole UART qui comprend la logique, les tampons et les pilotes de ligne et les tris. Le jeu de commandes mentionné précédemment serait utilisé pour lire ou écrire sur le matériel UART. Il convient probablement de mentionner que les périphériques USB sont interrogés par le PC, donc dans les cas où vous utilisez du code basé sur des événements, votre PC effectue en fait une interrogation pour déterminer que de nouvelles données sont arrivées - cela peut être différent d'une série native port, je ne sais pas.

La logique ci-dessus peut être implémentée en tant qu'ASIC dédié ou en utilisant un noyau de microcontrôleur dépouillé qui exécute le micrologiciel sur la ROM. S'il s'agit bien d'un noyau de microcontrôleur, alors j'imagine que l'UART y est connecté en tant que périphérique.

— Jon L
source

Et dans quelle mesure êtes-vous certain qu'aucun programme de micrologiciel n'est en cours d'exécution? Les microcontrôleurs nécessitent généralement moins de portes logiques que l'implémentation de matériel dédié ASIC équivalent. Il est vraiment difficile de distinguer un microcontrôleur d'un ASIC, si le micrologiciel du microcontrôleur n'est pas accessible à l'utilisateur.

— Ben Voigt

@Ben: Tu sais quoi? Je n'aurais probablement pas dû dire ça. La réponse a été modifiée en raison de mon ignorance. Je suis allé avec mon hypothèse intestinale après avoir regardé le diagramme, mais je suppose qu'il serait préférable d'abstraire de toute façon tous les détails uC potentiels. Je suppose que seuls ceux de FTDI le sauraient, et je suppose que cela revient aux coûts de licence de base par rapport au temps de développement interne.

— Jon L

1

Habituellement, lorsque vous avez un "protocole", vous vous retrouvez avec un "programme" pour le gérer ... même s'il fonctionne sur un moteur enfoui profondément dans un ASIC ou un FPGA. L'exception serait des choses où une vitesse aveuglément rapide l'emporte sur la complexité, où vous êtes susceptible de voir une machine d'état ou un parallélisme massif. Entre les deux se trouvent des moteurs où le chemin de calcul est construit hors de proportion avec la logique de contrôle - en quelque sorte l'idée originale derrière les processeurs DSP

— Chris Stratton

2

Il y a un microcontrôleur USB à l'intérieur qui parle d'un protocole propriétaire sur USB (d'où le besoin de pilotes) et le convertit en signaux UART "normaux" et vice-versa.

— Martin Thompson
source