¿Por qué los puertos USB a veces se denominan puertos serie y se denominan COM?

En lo que respecta a mi comprensión de los puertos de la computadora,

1. Un puerto serie es un conector de 9 pines como el que se muestra aquí y también se denomina puerto COM.
2. Los puertos USB son un estándar diferente de los puertos seriales.

¿Por qué entonces veo a menudo puertos USB llamados "puertos seriales" y, por ejemplo, en el IDE de Arduino, los puertos USB se identifican con el prefijo COM? Además, ¿por qué a veces se necesita un puerto COM virtual si no hay puertos serie involucrados? (Ejemplo: adaptador Prologix GPIB-USB).

Este uso del mismo nombre para describir dos cosas diferentes, creo que puede ser un poco confuso.

Estos no son puertos USB conocidos como puertos seriales. En su ejemplo, el Arduino tiene un dispositivo USB a serie (ya sea en forma de un segundo microcontrolador o un chip FTDI). Esto usará USB para comunicarse con la computadora y formar un puerto serie real para el mundo exterior, similar a los dongles USB Wi-Fi, o adaptadores USB LAN, adaptadores USB SATA, etc.

La clave es que, en muchos casos, el puerto serie no está disponible directamente para el usuario, ya que está "cableado" en el dispositivo (en este caso, conectado directamente al microcontrolador que está programando).

En teoría estricta, cualquier puerto que use comunicaciones en serie (casi cualquier bus moderno, incluido USB, que significa "Universal Serial Bus", si mi memoria me sirve) es un "puerto en serie". Sin embargo, en la mayoría de los casos, cuando las personas se refieren al "puerto serie", en realidad se refieren a un puerto que cumple con RS-232.

Es confuso porque Windows COM: los puertos provienen de un sistema de nombres definido en MS-DOS (b. 1980). Esto fue prácticamente copiado de CP / M (b. 1974) con algunas ideas tomadas de Unix. No anticiparon la adición de un bus de 'transporte' intermedio como USB.

Muchas cosas en Windows son sobrevivientes de la evolución de CP / M-> MS-DOS, como unidades de disco con nombre de letra, extensiones de nombre de archivo de 3 letras, archivos .EXE y .COM y la interfaz de comando del símbolo del sistema.

Otro son los nombres de los dispositivos: generalmente tres letras, que siempre terminan en dos puntos. COM: es un 'puerto de comunicaciones' en serie, LPT: una 'impresora de línea' (generalmente colgando de un puerto Centronics), NUL: vuelca todo lo que se le envía, CON: es la 'consola' (teclado y pantalla). Algunos de los que podría tener varios se numeran para diferenciarlos. COM: los puertos lo hacen, al igual que LPT: puertos, convirtiéndose en COM1: y LPT1: y así sucesivamente.

Un puerto COM: es un 'punto final': el extremo más alejado del enlace de comunicaciones desde el punto de vista de una PC con Windows. Al igual que muchas cosas en informática, el puente allí se ignora y es el componente remoto en el que está pensando, no el USB. Esto también es cierto para un teclado de PC (vinculado como CPU-PCIe-USB-kbd) o una unidad de red (vinculada como CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATA o similar).

USB también usa la idea de puntos finales. Un controlador USB puede conectar una PC host a todo tipo de hardware y proporcionarlos como recursos. Entonces, cuando vea el hardware conectado por USB, verá estos puntos finales. Un puerto COM virtual en un dispositivo USB es simplemente un puerto serie que sale de ese dispositivo esclavo USB como punto final. Windows le dará un número (COM1 :, COM27: etc.) y ese puerto serie puede ser reconocido y utilizado por cualquier programa que use la API estándar de Windows para COM: puertos.

Es posible que parte del hardware conectado por USB prefiera suplantar un puerto serie porque facilita el desarrollo del software de Windows. No es necesario escribir ningún controlador de dispositivo, lo que ahorra mucho trabajo: el dispositivo USB le dice a Windows que es un puerto serie. Desde el punto de vista de la PC, esto está bien si se comporta como un puerto serie (los bytes se envían y reciben en una secuencia en serie sin fin que siempre está abierta). Por lo tanto, hay beneficios para el desarrollador.

Para agregar a la respuesta de Joren Vaes : tenga en cuenta que algunas aplicaciones de software (como Arduino IDE) instalan un controlador de Windows que crea puertos "virtuales COM". Cuando esos puertos están activados, los sistemas operativos les dicen a los programas que hay un puerto COM disponible, que se parece a un puerto serie estándar [*], al cual los programas (como Arduino IDE, pero también cualquier otro) pueden enviar y recibir bits como a cualquier puerto serie. Bajo el capó, sin embargo, esos bits se envían a un cable USB. Dentro del tablero Arduino ocurre algo análogo.

[*] Y, por "puerto serie estándar", nos referimos al protocolo RS-232, el tipo que se transmitía tradicionalmente a través del conector DB-9 o DB-25. En nuestro contexto, no importa en absoluto que el USB también sea "serial".

Su comprensión de la diferencia entre el puerto COM y el puerto USB es correcta.

En pocas palabras, su pregunta, por qué algunos puertos USB están asignados por el sistema operativo como puertos "COM", es: hay dispositivos USB que implementan USB CDC (clase de dispositivo de comunicación). Estos dispositivos proporcionan un puente desde una interfaz USB terriblemente complicada a una interfaz tipo UART / RS-232 estándar. Para mayor transparencia para los usuarios, el sistema operativo carga controladores USB que imitan la capa de transporte como puerto COM, un puerto COM virtual. A continuación se presentan algunos detalles históricos y justificaciones para este enfoque.

El puerto COM utiliza conectores DB-9 / DB-15 (también conocido como serie RS-232 o UART), y los controladores para estos puertos se asignan físicamente al hardware de la PC, a direcciones específicas en el espacio de E / S. Este controlador COM se está volviendo obsoleto en las PC modernas y se extingue.

Al mismo tiempo, muchos MCU todavía utilizan la comunicación serie RS-232 como medio principal para comunicarse con el mundo periférico. La razón es que el hardware (y el software) para este tipo de enlace es muy simple y fácil de implementar. Además, toda la comunicación moderna de desarrollo / depuración de Android se realiza en el estilo de puerto COM. Además, muchos dispositivos de "comunicación" (como módems, incluido 4G LTE y superior), todavía usan la interfaz de estilo UART con el protocolo de control de tipo ASCII en varios puertos "COM".

Ahora los desarrolladores tienen un dilema, ¿cómo comunicarse con dichos microcontroladores si la PC de desarrollo del host no tiene puertos COM? La solución fue utilizar puertos USB y dispositivos USB especiales que unan el protocolo USB con la interfaz RS-232 de puerto COM. Hay dispositivos USB dedicados como chips FTDI, y muchos otros (Cypress, Microchip, etc.) hacen dispositivos que realizan esta función de puente.

Ahora, toda la comunicación nativa a estas MCU todavía se expresa en términos del protocolo RS-232, y la mayoría de los ejemplos de aplicaciones suponen el uso de alguna aplicación de Terminal (TeraTerm, HyperTerminal, etc.) para usar el enlace. Para comodidad del usuario, los puentes de USB a UART se proporcionan con controladores que representan el puerto como un puerto COM virtual. Todo el software moderno utiliza la virtualización del hardware COM, que proporciona una transición sin problemas a las PC "sin COM". Se convierte en una práctica común agregar un puente FTDI dedicado a los puertos UART en una plataforma de desarrollo MCU (y usar controladores FTDI en la PC host para hacer que el puerto USB se vea como el puerto COM), o incrustar el código de puente apropiado en el MCU mismo (si tiene funcionalidad USB nativa).

El enfoque directo es utilizar una placa externa de USB a UART y conectar el UART a la MCU en desarrollo. O, si una placa ya tiene el conector DB-9, hay dongles USB que se pueden conectar directamente a ella.

En todos los casos, el control UART nativo de MCU aparecerá en el lado del host como un puerto COM virtual, omitiendo todas las transformaciones intermedias de señal / protocolo. Es por eso que las personas hoy en día a menudo omiten la distinción entre puentes USB a UART y puertos COM.

Es muy confuso, pero no necesita preocuparse por eso. En primer lugar, piense en un UART que en sí mismo es un término genérico, pero piense en uno que produce un protocolo con un bit de inicio, uno o dos bits de parada, 7 u 8 generalmente bits de datos y, a veces, paridad que es par o impar; puede variar a partir de ahí, lo que lo hace mucho peor.

El UART está en niveles TTL, sea lo que sea que eso signifique. Solía ​​ser 5 V y ahora 3.3 V, 1.8 V o lo que sea; Quizás TTL es el término equivocado. ENTONCES tenía / tiene RS-232, RS-422, etc. Estos son estándares de VOLTAJE Y PIN, no estándares de protocolo. Es incorrecto mezclar los términos y decir RS-232 cuando se refiere a algún tipo de UART.

En el pasado, su UART estaba en sus placas base y deseaba algún tipo de conector al mundo exterior con niveles de voltaje que en ese momento tenían sentido y algún tipo de pinout / cable estándar. Por lo tanto, a menudo se encontró un estándar popular de 25 y 9 pines para varios periféricos, y en el mundo de Wintel PC se lo llamó puerto de comunicación o, a veces, puerto serie.

Claro, un puerto que transporta datos en serie puede y se llama puerto en serie, SPI, I²C, MDIO, UART, HDLC, SDLC, etc., y tal vez incluso USB y SCSI; podrías volverte loco con esto. Por lo general, un puerto serie significa algunos pines que puede obtener en un UART.

El mundo Unix / Linux dice en ttylugar de com/ serial/ uart, pero es lo mismo.

Ahora hay la IMPLEMENTACIÓN. Puede comprar un chip UART con alguna interfaz (sí, puede tener un SPI UART, que es serial en ambos extremos, o I²C UART o algún bus o USB dedicado, etc.). Incluso en el pasado, el UART tenía un bus a un lado que finalmente la CPU se comunicaba. Hoy tenemos FTDI y otros proveedores que hacen buenas soluciones USB UART, no hace que sea diferente algunas capas de interfaz entre el software y el UART y luego el otro lado del UART tiene alguna interfaz, ya sea nivel TTL / chip o RS-232C o RS-422, etc.

Al principio de Arduinos, a menudo usaba una placa FTDI USB a UART que también proporcionaba energía al Arduino. Algunos tienen esa alimentación USB y serial / UART en la placa Arduino y luego se conecta a la UART en el chip AVR (el mismo trato que algunos procesadores con algunas capas de buses para permitir que el software se comunique con una UART que tiene alguna interfaz en el otro lado, en este caso los pines en el borde del AVR, a niveles de voltaje de chip, TTL).

Dado que la funcionalidad UART no ha cambiado en décadas, ¿por qué debería cambiar la terminología del software o incluso las aplicaciones de software a nivel de aplicación? Escriba una aplicación TTY de Linux / Unix hace 10-15 años contra un chip UART en su placa base, y hay una buena posibilidad de que todavía funcione hoy con un USB a nivel TTL o USB a nivel RS-232C o RS-422 o cualquier pin / definición de nivel. Lo mismo ocurre con Windows, y tengo un código tan antiguo que todavía funciona en ambos. En el mundo de Windows se usa el término COM.

No he usado el sandbox de Arduino en mucho tiempo y, de ser así, habría estado en Linux, pero no me sorprendería si ese programa que es Java, si no recuerdo mal, es genérico y usa el nombre del sistema ttyS2en Linux y COM2 en ventanas

Al releer su pregunta, esto puede ir mucho más allá, aprovechando la cantidad de software ya existente que utiliza estas llamadas API. Nuevamente, durante décadas no hay razón por la que no pueda crear un puerto virtual en un software que lleve estos datos bidireccionales a casi cualquier cosa que se le ocurra. UART a Ethernet es muy común, y en las salas de servidores donde los servidores todavía usan mucho los puertos COM / TTY / RS-232, puede tener un servidor de terminal que tiene una serie de interfaces que puede conectar a una cantidad de servidores, luego Ethernet en el otro lado, luego, si elige no hacer telnet, puede instalar un controlador de puerto COM virtual.

Luego, su aplicación en su computadora cree que está hablando con un puerto COM, pero de hecho ese flujo de bytes está saltando a Ethernet y luego golpea el servidor terminal, ENTONCES, a un UART a cables de nivel RS-232C (pero no necesariamente pinout) a el servidor y viceversa de la misma manera.

A veces no hay ninguna razón para llegar a un UART real, por alguna razón, virtualice un puerto COM para que el software que se escribió para esas llamadas a la API todavía pueda funcionar. Tal vez podría pensar en el antiguo software bancario que todavía usamos que tiene una terminal tonta para una interfaz UART que tal vez en ese momento estaba cableada o entró en un módem para eventualmente un servidor. Puede hacerlo para que el software siga funcionando, a través de varias cantidades de emulación, incluido un puerto COM virtual que hoy probablemente solo baja Ethernet al servidor como una transmisión en serie (TCP / IP, por ejemplo).