Pourquoi les ports USB sont-ils parfois appelés ports série et appelés COM?
En ce qui concerne ma compréhension des ports informatiques,
- Un port série est une prise à 9 broches telle que celle montrée ici , elle est également appelée port COM.
- Les ports USB sont une norme différente des ports série.
Pourquoi vois-je souvent des ports USB appelés "ports série" et, par exemple, dans l'IDE Arduino, les ports USB sont identifiés par le préfixe COM? Aussi, pourquoi un port COM virtuel est-il parfois nécessaire si aucun port série n'est impliqué? (Exemple: adaptateur Prologix GPIB-USB.)
Cette utilisation du même nom pour décrire deux choses différentes peut être un peu déroutante.
Ce ne sont pas des ports USB appelés ports série. Dans votre exemple, l’Arduino possède un périphérique USB/série (sous la forme d’un second microcontrôleur ou d’une puce FTDI). Cela utilisera l’USB pour communiquer avec l’ordinateur et former un véritable port série vers le monde extérieur - similaire aux dongles USB Wi-Fi, aux adaptateurs USB LAN, aux adaptateurs USB SATA, etc.
La clé est que, dans de nombreux cas, le port série n'est pas disponible directement pour l'utilisateur, car il est "câblé" dans le périphérique (dans ce cas, connecté directement au microcontrôleur que vous programmez).
En théorie stricte, tout port utilisant des communications série (presque tout bus moderne - y compris USB, qui signifie "Universal Serial Bus", si ma mémoire est suffisante) est un "port série". Cependant, dans la plupart des cas, lorsque les utilisateurs font référence au "port série", ils désignent en fait un port conforme à RS-232.
C'est déroutant parce que Windows COM: les ports proviennent d'un système de nommage défini dans MS-DOS (b. 1980). Cela a été assez-copié de CP/M (né en 1974) avec quelques idées tirées d’Unix. Ils ne prévoyaient pas l'ajout d'un bus de transport intermédiaire comme l'USB.
Un certain nombre de choses dans Windows sont des survivants de l'évolution de CP/M-> MS-DOS, tels que les lecteurs de disque nommés par une lettre, les extensions de nom de fichier de 3 lettres, les fichiers .EXE et .COM et l'interface de commande avec invite de commande.
Une autre est les noms de périphérique: généralement trois lettres, se terminant toujours par deux points. COM: est un "port de communication" série, LPT: une "imprimante en ligne" (généralement suspendue à un port Centronics), NUL: sauvegarde tout ce qui lui est envoyé, CON: est la "console" (clavier et écran). Certains que vous pouvez avoir plusieurs numérotés pour les différencier. Les ports COM: comme les ports LPT: deviennent COM1: et LPT1: et ainsi de suite.
Un port COM: est un "point final": l'extrémité distante du lien de communication du point de vue d'un PC sous Windows. Comme beaucoup de choses dans l'informatique, le pont est ignoré et c'est le composant le plus éloigné auquel vous songez, pas l'USB. Ceci est également vrai d'un clavier de PC (lié en tant que CPU-PCIe-USB-kbd) ou d'un lecteur réseau (lié en tant que CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATA ou similaire).
USB utilise également l'idée de points finaux. Un contrôleur USB peut connecter un PC hôte à toutes sortes de matériels et les lui fournir en tant que ressources. Ainsi, lorsque vous voyez le matériel connecté par USB, vous voyez ces points de terminaison. Un port COM virtuel dans un périphérique USB est simplement un port série sortant de ce périphérique esclave USB en tant que point d'extrémité. Windows lui attribue un numéro (COM1 :, COM27: etc.) et ce port série peut être reconnu et utilisé par tout programme utilisant l’API Windows standard pour les ports COM:.
Certains matériels connectés par USB peuvent préférer emprunter l'identité d'un port série car cela facilite le développement du logiciel Windows. Aucun pilote de périphérique n'a besoin d'être écrit, ce qui épargne beaucoup de travail - le périphérique USB indique à Windows qu'il s'agit d'un port série. Du point de vue du PC, c'est très bien s'il se comporte comme un port série (les octets sont envoyés et reçus dans un flux série sans fin toujours ouvert). Il y a donc des avantages pour le développeur.
Pour ajouter à réponse de Joren Vaes : sachez que certaines applications logicielles (telles que Arduino IDE) installent un pilote Windows qui crée des ports "COM virtuels". Lorsque ces ports sont activés, le système d'exploitation indique aux programmes qu'un port COM est disponible, qui ressemble à un port série standard [*], vers lequel des programmes (comme Arduino IDE, mais aussi tout autre) peuvent envoyer et recevoir des bits tels que sur n'importe quel port série. Sous le capot, cependant, ces bits sont envoyés à un câble USB. Quelque chose d'analogue se produit à l'intérieur de la carte Arduino.
[*] Par "port série standard", nous entendons ici le protocole RS-232, celui qui était traditionnellement transmis via un connecteur DB-9 ou DB-25. Dans notre contexte, le fait que l'USB soit aussi "série" n'a aucune importance.
Votre compréhension de la différence entre le port COM et le port USB est correcte.
Répondez brièvement à votre question. Pourquoi certains ports USB sont-ils mappés par le système d’exploitation en tant que ports "COM"? Ces appareils permettent de passer d'une interface USB extrêmement compliquée à une interface standard de type UART/RS-232. Par souci de transparence pour les utilisateurs, le système d'exploitation charge les pilotes USB qui imitent la couche de transport en tant que port COM, un port COM virtuel. Certains détails historiques et justification de cette approche suivent.
Le port COM utilise des connecteurs DB-9/DB-15 (ou série RS-232 ou UART), et les contrôleurs de ces ports sont mappés physiquement dans le matériel du PC, à des adresses spécifiques dans l'espace d'E/S. Ce contrôleur COM devient obsolète sur les PC modernes et disparaît.
Dans le même temps, de nombreux MCU utilisent toujours la communication série RS-232 comme moyen principal de communiquer avec le monde périphérique. La raison en est que le matériel (et les logiciels) pour ce type de lien est très simple et facile à mettre en œuvre. De plus, toutes les communications de développement/débogage Android modernes se font dans un style de port COM. En outre, de nombreux périphériques "de communication" (en tant que modems, notamment la 4G LTE et les versions ultérieures), utilisent toujours l'interface de type UART avec un protocole de contrôle de type ASCII sur plusieurs ports "COM".
Maintenant, les développeurs ont un dilemme: comment communiquer avec de tels micro-contrôleurs si le PC de développement hôte ne dispose pas de ports COM? La solution consistait à utiliser des ports USB et des périphériques USB spéciaux établissant un pont entre le protocole USB et l'interface RS-232 du port COM. Il existe des périphériques USB dédiés, tels que les puces FTDI, et de nombreux autres (Cypress, Microchip, etc.) permettent de créer des périphériques qui remplissent cette fonction de pont.
Désormais, toutes les communications natives avec ces MCU sont toujours exprimées en termes de protocole RS-232 et la plupart des exemples d’application supposent l’utilisation de certaines applications Terminal (TeraTerm, HyperTerminal, etc.) pour utiliser le lien. Pour plus de commodité, les ponts USB-UART sont fournis avec des pilotes qui représentent le port en tant que port COM virtuel. Tous les logiciels modernes utilisent la virtualisation du matériel COM, ce qui permet une transition en douceur vers des PC "sans COM". Il devient courant d’ajouter un pont FTDI dédié aux ports UART sur une plate-forme de développement MCU (et d’utiliser des pilotes FTDI sur un ordinateur hôte pour que le port USB ressemble à un port COM. ), ou incorporer le code de pont approprié dans la MCU elle-même (si elle possède une fonctionnalité USB native).
L’approche directe consiste à utiliser un carte externe USB-to-UART et à relier le UART au MCU en cours de développement. Ou, si une carte possède déjà le connecteur DB-9, il existe dongles USB pouvant être connectés directement à celle-ci.
Dans tous les cas, le contrôle natif UART de la MCU apparaîtra côté hôte en tant que port COM virtuel, en ignorant toutes les transformations de signal/protocole intermédiaires. C'est pourquoi, de nos jours, les gens oublient souvent la distinction entre les ponts USB-UART et les ports COM.
C'est très déroutant, mais vous n'avez pas à vous en soucier. Tout d’abord, pensez à un UART qui est lui-même un terme générique, mais à celui qui produit un protocole avec un bit de début, un ou deux bits d’arrêt, 7 ou 8 bits de données, et parfois une parité qui est pair ou impair; cela peut varier, ce qui aggrave encore la situation.
Le UART est à TTL, peu importe ce que cela signifie. Il était de 5 V et maintenant de 3,3 V, 1,8 V ou autre; peut-être que TTL est le mauvais terme. ALORS vous avez/avez eu RS-232, RS-422, etc. Ce sont des normes de TENSION ET PIN, pas de normes de protocole. Il est incorrect de mélanger les termes et de dire RS-232 lorsque vous parlez d'une sorte d'UART.
À l'époque où votre UART se trouvait sur votre carte mère, vous souhaitiez une sorte de connecteur vers le monde extérieur avec des niveaux de tension convenables à l'époque et une sorte de brochage/câble standard. Ainsi, un standard populaire à 25 et 9 broches a souvent été trouvé pour divers périphériques, et dans le monde PC Wintel, cela s'appelait un port COMmunication ou parfois un port série.
Bien sûr, un port qui transporte des données série peut être appelé port série, SPI, I²C, MDIO, UART, HDLC, SDLC, etc., et peut-être même USB et SCSI; vous pourriez devenir fou avec ça. Habituellement, un port série signifie des broches que vous pouvez obtenir sur un UART.
Le monde Unix/Linux dit tty au lieu de com/serial/uart, mais c'est la même chose.
Maintenant, il y a la MISE EN ŒUVRE. Vous pouvez acheter une puce UART avec une interface (yep, vous pouvez avoir un UART SPI, qui est en série aux deux extrémités, ou I²C UART ou un bus dédié ou USB, etc.). Même à l'époque, le UART avait un bus sur un côté qui permettait au processeur de communiquer. Aujourd’hui, nous avons FTDI et d’autres fournisseurs qui fabriquent des solutions Nice USB UART, mais ne différencient pas certaines couches d’interface entre le logiciel et le UART, puis l’autre côté de la UART possède une interface, que ce soit au niveau TTL/puce, RS-232C ou RS-422, etc.
Au début des Arduinos, vous utilisiez souvent une carte FTDI USB-to-UART qui alimentait également l’Arduino. Certains ont cette alimentation USB et ce port série/UART sur la carte Arduino elle-même, qui est ensuite raccordée à la carte UART de la puce AVR (le même traitement est appliqué à certains processeurs avec certaines couches de bus pour permettre au logiciel de communiquez avec un UART qui possède une interface de l’autre côté, dans ce cas les broches situées sur le bord de l’AVR, à des niveaux de tension de puce, TTL).
Puisque la fonctionnalité UART n'a pas changé depuis des décennies, pourquoi la terminologie logicielle ou même les applications logicielles devraient-elles changer au niveau de l'application? Ecrivez une application Linux/Unix TTY il y a 10-15 ans contre une puce UART sur votre carte mère. Il y a de fortes chances qu'elle fonctionne encore aujourd'hui avec un port USB jusqu'au niveau TTL ou USB niveau RS-232C ou RS-422 ou autre définition de broche/niveau. Il en va de même pour Windows, et j'ai un code aussi ancien qui fonctionne toujours sur les deux. Dans le monde Windows, le terme COM est utilisé.
Je n’ai pas utilisé le bac à sable Arduino depuis un moment et si tel avait été le cas sous Linux, je ne serais pas surpris si ce programme qui est Java, si je me souviens bien, est générique et utilise le nom du système, de sorte que ttyS2 est sous Linux et COM2 sur les fenêtres.
Relisez votre question, cela peut aller beaucoup plus loin, en tirant parti de la quantité de logiciels déjà existants qui utilise ces appels d'API. Encore une fois, pendant des décennies, il n’ya aucune raison pour que vous ne puissiez pas créer un port virtuel dans un logiciel qui transfère ces données bidirectionnelles à peu près à tout ce que vous pouvez penser. UART à Ethernet est très courant, et dans les salles de serveurs où les serveurs utilisent encore beaucoup les ports COM/TTY/RS-232, vous pouvez avoir un serveur de terminal avec plusieurs interfaces que vous pouvez connecter. sur un certain nombre de serveurs, puis sur Ethernet de l'autre côté, puis, si vous choisissez de ne pas effectuer de connexion Telnet, vous pouvez installer un pilote de port COM virtuel.
Ensuite, votre application sur votre ordinateur pense qu’elle communique avec un port COM, mais en fait, ce flux d’octets saute sur Ethernet, puis frappe le serveur de terminal, THEN, sur un niveau UART à RS-232C (mais pas forcément) les câbles vers le serveur et le retour de la même manière.
Parfois, il n’ya aucune raison de le transformer en véritable UART. Pour une raison quelconque, virtualisez un port COM afin que le logiciel écrit pour ces appels d’API puisse toujours fonctionner. Vous pourriez peut-être penser au logiciel bancaire ancien que nous utilisons encore et qui a un terminal idiot pour une interface UART qui était peut-être de retour dans la journée et qui est passé dans un modem pour devenir un serveur. Vous pouvez faire en sorte que le logiciel fonctionne toujours, avec différentes émulations, notamment un port COM virtuel qui, aujourd’hui, passe probablement par Ethernet au serveur en tant que flux série (TCP/IP par exemple).