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).
