Это очень запутанно, но вам не нужно об этом беспокоиться. Прежде всего, подумайте о 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, I2C, 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).
