Чому порти USB іноді називають послідовними портами і називають COM?

Наскільки я розумію комп'ютерні порти,

1. Послідовний порт - це 9-контактний штекер, такий як показаний тут, і його також називають COM-портом.
2. USB-порти відрізняються від стандартних портів.

Чому тоді я часто бачу порти USB, які називаються "послідовними портами", і, наприклад, в Arduino IDE, порти USB ідентифікуються за допомогою префіксу COM? Крім того, чому іноді потрібен віртуальний COM-порт, якщо немає жодних послідовних портів? (Приклад: GPRS-USB-адаптер Prologix.)

Використання однойменного опису для опису двох різних речей, я думаю, може бути трохи заплутаним.

Це не порти USB, що називаються послідовними портами. У вашому прикладі Arduino має USB-до-серійний пристрій (або у вигляді другого мікроконтролера, або мікросхеми 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, таких як дисководи з літерними назвами, розширення імен файлів на 3 літери, файли .EXE та .COM та інтерфейс командного рядка Command Prompt.

Інша - це назви пристроїв: зазвичай три букви, які завжди закінчуються двокрапкою. 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-пристрої - це просто послідовний порт, що виходить із цього підлеглого пристрою в якості кінцевої точки. Windows надасть йому номер (COM1 :, COM27: тощо), і цей послідовний порт може бути розпізнаний та використаний будь-якою програмою, використовуючи стандартний API Windows для портів 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, і більшість прикладів додатків передбачає використання деякої програми Terminal (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 і т. Д. Це стандарти НАЛОТИ ТА ПІН, а не стандарти протоколу. Неправильно змішувати терміни і говорити RS-232, коли ви маєте на увазі якесь UART.

Ще в той день, коли ваш UART був на материнських платах, і ви хотіли якийсь роз'єм для зовнішнього світу з рівнем напруги, який на той час мав сенс і якоюсь стандартною розеткою / кабелем. Так популярний стандарт 25 та 9-контактних часто зустрічався для різних периферійних пристроїв, і в світі Wintel PC це називали портом комунікацій або іноді послідовним портом.

Звичайно, порт, який несе серійні дані, може і називається послідовним портом, SPI, I²C, MDIO, UART, HDLC, SDLC тощо, і, можливо, навіть USB і SCSI; ви можете зійти з розуму з цим. Зазвичай послідовний порт означає деякі шпильки, які ви можете отримати в UART.

Світ Unix / Linux говорить ttyзамість com/ serial/ uart, але це те саме.

Тепер є ВПРОВАДЖЕННЯ. Ви можете придбати чип UART з деяким інтерфейсом на ньому (так, ви можете мати SPI UART, який є послідовним на обох кінцях, або I²C UART або якусь виділену шину або USB тощо). Навіть у той час, коли UART мав автобус на одній стороні, через який процесор спілкувався. Сьогодні у нас є FTDI та інші постачальники, які роблять приємні рішення USB UART, не відрізняються деякими шарами інтерфейсу між програмним забезпеченням та UART, а потім інша сторона UART має певний інтерфейс, будь то рівень TTL / чіп або RS-232C або RS-422 тощо.

На початку Arduinos ви часто використовували плату FTDI USB-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 в Ethernet дуже поширений, і в серверних кімнатах, де сервери все ще дуже часто використовують порти COM / TTY / RS-232, ви можете мати термінальний сервер, який має ряд інтерфейсів, які можна підключити до декількох серверів, потім Ethernet з іншого боку, то якщо ви вирішите не входити в telnet, ви можете встановити віртуальний драйвер COM-порта.

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

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