Почему порты USB иногда называют последовательными портами и называются COM?

Насколько мое понимание компьютерных портов идет,

1. Последовательный порт представляет собой 9-контактный разъем, такой как показан здесь, и он также называется COM-портом.
2. USB-порты отличаются от стандартных последовательных портов.

Почему тогда я часто вижу порты USB, называемые «последовательными портами», и, например, в IDE Arduino порты USB идентифицируются префиксом COM? Кроме того, зачем иногда нужен виртуальный COM-порт, если нет последовательных портов? (Пример: адаптер Prologix GPIB-USB.)

Это использование одного и того же имени для описания двух разных вещей, я думаю, может быть немного запутанным.

Это не порты USB, называемые последовательными портами. В вашем примере Arduino имеет устройство USB-to-serial (либо в виде второго микроконтроллера, либо чипа FTDI). При этом USB будет использоваться для связи с компьютером и формирования фактического последовательного порта для внешнего мира - аналогично USB-адаптерам Wi-Fi или адаптерам USB LAN, адаптерам USB SATA и т. Д.

Ключевым моментом является то, что во многих случаях последовательный порт недоступен непосредственно пользователю, так как он «жестко» подключен к устройству (в этом случае подключается непосредственно к микроконтроллеру, который вы программируете).

В строгой теории любой порт, использующий последовательную связь (почти любая современная шина, включая USB, которая обозначает «Универсальная последовательная шина», если мне не изменяет память), является «последовательным портом». Однако в большинстве случаев, когда люди ссылаются на «последовательный порт», они фактически ссылаются на порт, который соответствует RS-232.

Это сбивает с толку, потому что Windows COM: порты происходят из системы имен, определенной еще в MS-DOS (р. 1980). Это было в значительной степени скопировано из CP / M (р. 1974) с некоторыми идеями, взятыми из Unix. Они не ожидали добавления промежуточной «транспортной» шины, такой как USB.

В Windows есть несколько вещей, переживших эволюцию CP / M-> MS-DOS, такие как дисковые накопители с буквенными именами, трехбуквенные расширения имен файлов, файлы .EXE и .COM и командный интерфейс командной строки.

Другое имя устройства: обычно три буквы, всегда заканчивающиеся двоеточием. COM: это последовательный «коммуникационный порт», LPT: «линейный принтер» (обычно свисающий с порта Centronics), NUL: выводит все, что ему отправлено, CON: «консоль» (клавиатура и экран). Некоторые из них могут быть пронумерованы, чтобы различать их. COM: порты, как и LPT: порты, становятся COM1: и LPT1: и так далее.

COM: порт - это «конечная точка»: дальний конец канала связи с точки зрения ПК с Windows. Как и многие другие вещи в вычислительной технике, мост там игнорируется, и вы думаете о компоненте дальнего конца, а не о USB. Это также верно для клавиатуры ПК (связанной как CPU-PCIe-USB-kbd) или сетевого диска (связанной как CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATA или аналогичной).

USB также использует идею конечных точек. Контроллер USB может подключать хост-компьютер ко всем видам оборудования и предоставлять их ему в качестве ресурсов. Поэтому, когда вы видите оборудование, подключенное через USB, вы видите эти конечные точки. Виртуальный порт COM: на USB-устройстве - это просто последовательный порт, выходящий из подчиненного USB-устройства в качестве конечной точки. Windows присвоит ему номер (COM1:, COM27: и т. Д.), И этот последовательный порт может быть распознан и использован любой программой, использующей стандартный Windows API для портов COM :.

Некоторые устройства, подключенные к USB, могут предпочесть выдавать себя за последовательный порт, потому что это облегчает разработку программного обеспечения для Windows. Не нужно писать драйвер устройства, что экономит много работы - USB-устройство сообщает Windows, что это последовательный порт. С точки зрения ПК, это нормально, если он ведет себя как последовательный порт (байты отправляются и принимаются в бесконечном последовательном потоке, который всегда открыт). Так что есть преимущества для разработчика.

Чтобы добавить к ответу Джорена Вейса : учтите, что некоторые программные приложения (например, Arduino IDE) устанавливают драйвер Windows, который создает «виртуальные COM-порты». Когда эти порты активированы, операционные системы сообщают программам, что имеется доступный COM-порт, который выглядит как стандартный последовательный порт [*], на который программы (например, Arduino IDE, но также и любые другие) могут отправлять и получать биты, такие как на любой последовательный порт. Однако под капотом эти биты отправляются на USB-кабель. Внутри платы Arduino происходит нечто аналогичное.

[*] И под «стандартным последовательным портом» здесь подразумевается протокол RS-232, тип, который традиционно передавался через разъем DB-9 или DB-25. В нашем контексте совершенно неважно, что USB тоже «последовательный».

Ваше понимание разницы между COM-портом и USB-портом является правильным.

Краткий ответ на ваш вопрос, почему некоторые порты USB отображаются ОС как порты «COM»: есть устройства USB, которые реализуют USB CDC (класс коммуникационных устройств). Эти устройства обеспечивают мост от ужасно сложного интерфейса USB к стандартному интерфейсу типа UART / RS-232. Для прозрачности для пользователей операционная система загружает драйверы USB, которые имитируют транспортный уровень как COM-порт, виртуальный COM-порт. Ниже приводятся некоторые исторические детали и обоснование этого подхода.

В COM-порту используются разъемы DB-9 / DB-15 (последовательный порт RS-232 или UART), и контроллеры для этих портов физически сопоставляются с аппаратным обеспечением ПК по определенным адресам в пространстве ввода-вывода. Этот COM-контроллер устаревает в современных ПК и вымирает.

В то же время многие MCU по-прежнему используют последовательную связь RS-232 в качестве основного средства связи с периферийным миром. Причина в том, что аппаратное обеспечение (и программное обеспечение) для такого рода ссылок очень просто и легко реализуемо. Более того, все современные средства разработки и отладки для Android выполнены в стиле COM-порта. Кроме того, многие «коммуникационные» устройства (такие как модемы, включая 4G LTE и выше) все еще используют интерфейс в стиле UART с протоколом управления типа ASCII через несколько «COM» портов.

Теперь у разработчиков возникает дилемма: как общаться с такими микроконтроллерами, если на компьютере разработки хоста нет COM-портов? Решением было использование USB-портов и специальных USB-устройств, которые соединяют USB-протокол с COM-портом интерфейса RS-232. Существуют специальные USB-устройства, такие как микросхемы FTDI, и многие другие (Cypress, Microchip и т. Д.) Создают устройства, которые выполняют эту функцию моста.

Теперь вся собственная связь с этими MCU по-прежнему выражается в виде протокола RS-232, и в большинстве примеров приложений предполагается использование какого-либо приложения терминала (TeraTerm, HyperTerminal и т. Д.) Для использования канала. Для удобства пользователей мосты USB-UART снабжены драйверами, которые представляют порт как виртуальный COM-порт. Все современное программное обеспечение использует виртуализацию оборудования COM, что обеспечивает плавный переход на ПК без COM. Обычной практикой является добавление выделенного моста FTDI к портам UART на платформе разработки MCU (и использование драйверов FTDI на хост-ПК, чтобы порт USB выглядел как COM-порт), или встраивание соответствующего кода моста в сам MCU (если он имеет встроенную функциональность USB).

Прямой подход заключается в использовании внешней платы USB-UART и подключении UART к разрабатываемому MCU. Или, если на плате уже есть разъем DB-9, есть USB-ключи, которые можно подключить к ней напрямую.

Во всех случаях встроенный элемент управления UART для MCU будет отображаться на стороне хоста как виртуальный COM-порт, пропуская все промежуточные преобразования сигнал / протокол. Вот почему люди в наши дни часто пропускают различие между мостами USB-UART и COM-портами.

Это очень запутанно, но вам не нужно об этом беспокоиться. Прежде всего, подумайте о UART, который сам по себе является общим термином, но подумайте о том, который создает протокол со стартовым битом, одним или двумя стоповыми битами, 7 или 8 обычно битами данных, а иногда и четностью, которая является четной или нечетной; это может варьироваться оттуда, что делает его намного хуже.

UART находится на уровне TTL, что бы это ни значило. Раньше было 5 В, а теперь 3,3 В, 1,8 В или что-то еще; возможно, TTL - неправильный термин. ТОГДА вы имели / имеете RS-232, RS-422 и т. Д. Это стандарты VOLTAGE и PIN, а не протоколы. Неправильно смешивать термины и произносить RS-232, когда вы имеете в виду какой-то UART.

В свое время ваш UART был на ваших материнских платах, и вы хотели какой-то разъем для внешнего мира с уровнями напряжения, которые в то время имели смысл, и своего рода стандартную распиновку / кабель. Таким образом, популярный 25- и 9-контактный стандарт часто использовался для различных периферийных устройств, и в мире ПК Wintel его называли портом COM-связи или иногда последовательным портом.

Конечно, порт, который несет последовательные данные, может и называется последовательным портом, SPI, I²C, MDIO, UART, HDLC, SDLC и т. Д., И, возможно, даже USB и SCSI; Вы можете сойти с ума от этого. Обычно последовательный порт означает некоторые контакты, которые вы можете получить в UART.

Мир Unix / Linux говорит ttyвместо com/ serial/ uart, но это то же самое.

Сейчас идет РЕАЛИЗАЦИЯ. Вы можете купить какой-нибудь чип UART с некоторым интерфейсом (да, у вас может быть SPI UART, который является последовательным на обоих концах, или I2C UART, или какая-то выделенная шина или USB и т. Д.). Даже в тот день у UART была одна шина с одной стороны, через которую в конечном итоге общался процессор. Сегодня у нас есть FTDI и другие поставщики, которые делают хорошие решения USB UART, не отличая некоторые уровни интерфейса между программным обеспечением и UART, и тогда другая сторона UART имеет некоторый интерфейс, будь то уровень TTL / чип или RS-232C или RS-422 и т. Д.

Ранние Arduinos Вы часто использовали плату FTDI USB-to-UART, которая также обеспечивала питание Arduino. У некоторых есть то питание USB и последовательный / UART на самой плате Arduino, которое затем подключается через плату к UART на микросхеме AVR (то же самое относится к некоторым процессорам с несколькими уровнями шин, чтобы программное обеспечение могло взаимодействовать с UART, который имеет некоторый интерфейс на другой стороне этого, в этом случае контакты на краю AVR, на уровнях напряжения микросхемы, TTL).

Поскольку функциональность UART не менялась десятилетиями, почему терминология программного обеспечения или даже программные приложения должны меняться на уровне приложений? Напишите приложение Linux / Unix TTY 10-15 лет назад против чипа UART на материнской плате, и есть большая вероятность, что оно все еще работает сегодня с уровнем USB-TTL или уровнем USB-RS-232C, RS-422 или любым другим контактом. / определение уровня. То же самое касается Windows, и у меня есть старый код, который все еще работает на обоих. В мире Windows используется термин COM.

Я не использовал песочницу Arduino некоторое время, и если бы это было так в Linux, но я не удивлюсь, если эта программа, которая на Java, если я правильно помню, является универсальной и использует системное имя так же и ttyS2в Linux и COM2 на окнах.

Перечитав ваш вопрос, вы можете пойти гораздо дальше, воспользовавшись уже существующим количеством программного обеспечения, которое использует эти вызовы API. Опять же, на протяжении десятилетий нет причин, по которым вы не можете создать виртуальный порт в программном обеспечении, которое переносит эти двунаправленные данные практически во все, что вы можете себе представить. UART to Ethernet является очень распространенным, и в серверных комнатах, где серверы все еще очень часто используют порты COM / TTY / RS-232, вы можете иметь терминальный сервер, который имеет несколько интерфейсов, которые вы можете подключить к ряду серверов, затем Ethernet с другой стороны, затем, если вы решите не подключаться к telnet, вы можете установить драйвер виртуального COM-порта.

Тогда ваше приложение на вашем компьютере думает, что оно взаимодействует с COM-портом, но на самом деле поток байтов переходит на Ethernet, а затем подключается к терминальному серверу, ТОГ, к уровням от UART до уровня RS-232C (но не обязательно распиновка) для сервер и обратно одинаково.

Иногда нет никакой причины фактически делать это в реальном UART, по любой причине виртуализировать COM-порт, чтобы программное обеспечение, которое было написано для этих вызовов API, все еще могло работать. Возможно, вы могли бы подумать о древнем банковском программном обеспечении, которое мы все еще используем, которое имеет тупой терминал с интерфейсом UART, который, возможно, когда-то был зашит или был подключен к модему, чтобы в конечном итоге стать сервером. Вы можете сделать так, чтобы программное обеспечение все еще работало, посредством различных эмуляций, включая виртуальный COM-порт, который сегодня, вероятно, просто переходит по Ethernet к серверу в виде последовательного потока (например, TCP / IP).