Por que as portas USB são às vezes chamadas de portas seriais e chamadas COM?

Question

No que diz respeito à minha compreensão das portas de computador,

1. Uma porta serial é uma tomada de 9 pinos, como a mostrada aqui e também é chamada de porta COM.
2. As portas USB são um padrão diferente das portas seriais.

Por que muitas vezes eu vejo portas USB chamadas "portas seriais" e, por exemplo, no Arduino IDE, as portas USB são identificadas pelo prefixo COM? Além disso, por que uma porta COM virtual às vezes é necessária se não houver portas seriais envolvidas? (Exemplo: adaptador Prologix GPIB-USB.)

Esse uso do mesmo nome para descrever duas coisas diferentes que eu acho pode ser um pouco confuso.

    

Answer 1

Estas não são portas USB referidas como portas seriais. No seu exemplo, o Arduino tem um dispositivo USB-para-serial (na forma de um segundo microcontrolador ou um chip FTDI). Isso usará USB para se comunicar com o computador e formar uma porta serial real para o mundo externo - semelhante a dongles USB Wi-Fi, adaptadores LAN USB, adaptadores SATA USB, etc.

A chave é que, em muitos casos, a porta serial não está disponível diretamente para o usuário, como é "hard wired" no dispositivo (neste caso, conectado diretamente ao microcontrolador que você está programando).

Em teoria estrita, qualquer porta usando comunicação serial (quase qualquer barramento moderno - incluindo USB, que significa "Universal Serial Bus", se minha memória me serve) é uma "porta serial". No entanto, na maioria dos casos, quando as pessoas se referem à "porta serial", elas realmente se referem a uma porta que está em conformidade com a RS-232.

    

Answer 2

É confuso porque as portas COM do Windows vêm de um sistema de nomes definido no MS-DOS (b. 1980). Isso foi praticamente copiado do CP / M (n. 1974) com algumas idéias tiradas do Unix. Eles não previram a adição de um ônibus intermediário "transporte" como o USB.

Algumas coisas no Windows são sobreviventes da evolução do CP / M > MS-DOS, como unidades de disco com nomes de letras, extensões de nome de arquivo de 3 letras, arquivos .EXE e .COM e a interface de comando do Prompt de Comando. .

Outro é o nome do dispositivo: geralmente três letras, sempre terminando em dois pontos. COM: é uma 'porta de comunicações' serial, LPT: uma 'impressora de linha' (geralmente pendurada em uma porta Centronics), NUL: despeja o que for enviado para ela, CON: é o 'console' (teclado e tela). Alguns que você poderia ter vários são numerados para diferenciá-los. COM: portas fazem, assim como LPT: portas, tornando-se COM1: e LPT1: e assim por diante.

Uma COM: port é um 'endpoint': o extremo do link de comunicações do ponto de vista de um PC com Windows. Como muitas coisas na computação, a bridge lá é ignorada e é o componente mais distante que você está pensando, não o USB. Isso também é verdade para um teclado de PC (vinculado como CPU-PCIe-USB-kbd) ou uma unidade de rede (vinculada como CPU-PCIe-LAN-LAN-PCIe-CPU-SATA ou similar).

O USB também usa a ideia de endpoints. Um controlador USB pode conectar um PC host a todos os tipos de hardware e fornecê-los a ele como recursos. Então, quando você vê o hardware conectado por USB, você vê esses pontos de extremidade. Uma porta COM: virtual em um dispositivo USB é simplesmente uma porta serial saindo desse dispositivo escravo USB como um endpoint. O Windows fornecerá um número (COM1 :, COM27: etc.) e essa porta serial poderá ser reconhecida e usada por qualquer programa usando a API padrão do Windows para COM: ports.

Alguns hardwares conectados a USB podem preferir representar uma porta serial, pois facilita o desenvolvimento do software Windows. Nenhum driver de dispositivo precisa ser gravado, o que economiza muito trabalho - o dispositivo USB informa ao Windows que é uma porta serial. Do ponto de vista do PC, isso é bom se se comportar como uma porta serial (bytes são enviados e recebidos em um fluxo serial sem fim que está sempre aberto). Então, há benefícios para o desenvolvedor.

    

Answer 3

Para adicionar a resposta de Joren Vaes : esteja ciente de que alguns aplicativos de software (como o Arduino IDE) instalam um Windows driver que cria portas "COM" virtuais. Quando essas portas são ativadas, os sistemas operacionais informam aos programas que há uma porta COM disponível, que se parece com uma porta serial padrão [*], para a qual programas (como o Arduino IDE, mas também qualquer outro) podem enviar e receber bits como para qualquer porta serial. Sob o capô, no entanto, esses bits são enviados para um cabo USB. Dentro da placa do Arduino ocorre algo análogo.

[*] E, por "porta serial padrão" aqui queremos dizer o protocolo RS-232, o tipo que foi tradicionalmente transmitido via conector DB-9 ou DB-25. Em nosso contexto, não importa que o USB também seja "serial".

    

Answer 4

Sua compreensão da diferença entre a porta COM e a porta USB está correta.

Curto responder a sua pergunta, porque algumas portas USB são mapeadas pelo sistema operacional como portas "COM", é: existem dispositivos USB que implementam o CDC USB (Classe de dispositivo de comunicação). Esses dispositivos fornecem uma ponte de interface USB extremamente complicada para uma interface padrão tipo UART / RS-232. Para a transparência para os usuários, o sistema operacional carrega os drivers USB que imitam a camada de transporte como porta COM, uma porta COM virtual. Alguns detalhes históricos e justificativas para essa abordagem seguem.

A porta COM usa conectores DB-9 / DB-15 (também conhecidos como serial RS-232 ou UART) e os controladores para essas portas são mapeados fisicamente para o hardware do PC, para endereços específicos no espaço de E / S. Este controlador COM está ficando obsoleto em PCs modernos e é extinto.

Ao mesmo tempo, muitos MCU ainda usam a comunicação serial RS-232 como principal meio de comunicação com o mundo periférico. A razão é que o hardware (e software) para esse tipo de link é muito simples e fácil de implementar. Mais, toda a comunicação moderna de desenvolvimento / depuração do Android é feita no estilo da porta COM. Além disso, muitos dispositivos de "comunicação" (como modems, incluindo 4G LTE e superior), ainda usam a interface estilo UART com o protocolo de controle do tipo ASCII em várias portas "COM".

Agora os desenvolvedores têm um dilema, como se comunicar com esses micro-controladores se o PC de desenvolvimento do host não tiver portas COM? A solução foi usar portas USB e dispositivos USB especiais que conectam o protocolo USB com a interface COM-port RS-232. Existem dispositivos USB dedicados como chips FTDI, e muitos outros (Cypress, Microchip, etc.) tornam dispositivos que executam essa função de ponte.

Agora, todas as comunicações nativas para esses MCUs ainda são expressas em termos do protocolo RS-232, e a maioria dos exemplos de aplicativos pressupõe o uso de algum aplicativo Terminal (TeraTerm, HyperTerminal, etc.) para usar o link. Para conveniência do usuário, as pontes USB-para-UART são fornecidas com drivers que representam a porta como uma porta COM virtual. Todos os softwares modernos usam a virtualização do hardware COM, o que proporciona uma transição suave para os PCs "que não usam". Torna-se uma prática comum adicionar uma ponte dedicada FTDI às portas UART em uma plataforma de desenvolvimento de MCU (e usar drivers FTDI em PC host para fazer com que a porta USB se pareça com a porta COM) ou insira o código de ponte apropriado no próprio MCU (se tiver a funcionalidade USB nativa).

A abordagem correta é usar um placa USB-to-UART externa e conecte o UART ao MCU em desenvolvimento. Ou, se uma placa já tiver o conector DB-9, existem dongles USB que podem ser conectados diretamente para isso.

Em todos os casos, o controle UART nativo do MCU aparecerá no lado do host como uma porta COM virtual, pulando todas as transformações intermediárias de sinal / protocolo. É por isso que hoje em dia as pessoas ignoram a distinção entre as pontes USB e UART e as portas COM.

    

Answer 5

É muito confuso, mas você não precisa se preocupar com isso. Primeiramente, pense em uma UART que em si é um termo genérico, mas pense em uma que produza um protocolo com um bit inicial, um ou dois stop bits, 7 ou 8 geralmente bits de dados e, às vezes, paridade que é par ou ímpar; pode variar de lá, o que torna isso muito pior.

A UART está nos níveis TTL, o que isso significa. Ela costumava ser 5 V e agora 3,3 V, 1,8 V ou qualquer outra coisa; talvez o TTL seja o termo errado. ENTÃO você tinha / tem RS-232, RS-422, etc. Estes são os padrões VOLTAGE AND PIN, não os padrões de protocolo. É incorreto misturar os termos e dizer RS-232 quando você quer dizer algum tipo de UART.

De volta ao dia em que sua UART estava em suas placas-mãe e você desejava algum tipo de conector para o mundo externo com níveis de tensão que na época faziam sentido e algum tipo de pinagem / cabo padrão. Assim, um padrão popular de 25 e 9 pinos foi encontrado com freqüência em vários periféricos, e no mundo do Wintel PC isso era chamado de porta de comunicação ou, às vezes, de porta serial.

Claro, uma porta que transporta dados seriais pode e é chamada de porta serial, SPI, I²C, MDIO, UART, HDLC, SDLC, etc., e talvez até USB e SCSI; você poderia ficar louco com isso. Normalmente, uma porta serial significa alguns pinos que você pode obter em uma UART.

O mundo Unix / Linux diz tty em vez de com / serial / uart , mas é a mesma coisa.

Agora, há a IMPLEMENTAÇÃO. Você pode comprar algum chip UART com alguma interface (sim, você pode ter um SPI UART, que é serial em ambas as extremidades, ou I2C UART ou algum barramento dedicado ou USB, etc.). Mesmo no mesmo dia, a UART tinha um barramento de um lado que, em última análise, a CPU estava se comunicando. Hoje nós temos FTDI e outros fornecedores que fazem boas soluções UART USB, não faz com que seja diferente algumas camadas de interface entre o software e a UART e então o outro lado da UART tem alguma interface, seja em nível TTL / chip ou RS-232C ou RS-422, etc.

Primeiros Arduinos você freqüentemente usava uma placa FTDI USB-to-UART que também fornecia energia para o Arduino. Alguns têm esse poder USB e serial / UART na placa Arduino em si e, em seguida, que é ligado através da placa para o UART no chip AVR (mesmo negócio algum processador com algumas camadas de ônibus para permitir software para se comunicar com um UART que tem alguma interface do outro lado, neste caso os pinos na borda do AVR, nos níveis de tensão do chip, TTL).

Como a funcionalidade UART não mudou em décadas, por que a terminologia do software ou mesmo os aplicativos de software devem ser alterados no nível do aplicativo? Escreva um aplicativo Linux / Unix TTY 10-15 anos atrás contra um chip UART na sua placa-mãe, e há uma boa chance de que ele ainda funcione hoje com um nível USB para TTL ou USB para o nível RS-232C ou RS-422 ou qualquer pino / definição de nível. O mesmo vale para o Windows, e tenho código antigo que ainda funciona em ambos. No mundo do Windows, o termo COM é usado.

Eu não usei o sandbox do Arduino há algum tempo e, se assim fosse, estaria no Linux, mas não ficaria surpreso se o programa que é Java, se bem me lembro, for genérico e usar o nome do sistema, então ttyS2 no Linux e COM2 no Windows.

Para reler sua pergunta, isso pode ir muito além, aproveitando a quantidade de software já existente que usa essas chamadas de API. Novamente, por décadas, não há razão para que você não possa criar uma porta virtual em um software que carregue esses dados bidirecionais para praticamente qualquer coisa que você possa imaginar. UART para Ethernet é muito comum, e em salas de servidores onde os servidores ainda usam muito as portas COM / TTY / RS-232, você pode ter um servidor de terminal que possui um número de interfaces que você pode conectar a um número de servidores, em seguida, Ethernet no outro lado, então se você optar por não fazer telnet, você pode instalar um driver de porta COM virtual.

Em seguida, seu aplicativo em seu computador acha que está falando com uma porta COM, mas na verdade esse fluxo de bytes está pulando na Ethernet e atingindo o servidor de terminal, ENTÃO, em um nível UART para RS-232C (mas não necessariamente pinagem) ) cabos para o servidor e de volta da mesma maneira.

Às vezes, não há motivo para realmente chegar a uma UART real, seja qual for a razão, virtualizar uma porta COM para que o software que foi gravado para essas chamadas de API ainda funcione. Talvez você possa pensar sobre o antigo software bancário que ainda usamos, que tem um terminal idiota para uma interface UART, que talvez no passado tivesse sido programado ou tivesse entrado em um modem para eventualmente ser um servidor. Você pode fazê-lo de modo que o software ainda funcione, através de várias quantidades de emulação, incluindo uma porta COM virtual que, hoje, provavelmente simplesmente desce Ethernet para o servidor como um fluxo serial (TCP / IP, por exemplo).