Неизвестный UART: микросхемы
Как было сказано в предыдущей статье, UART не является формализованным стандартом и, следовательно, при его использовании имеет смысл опираться на практику реализаций данного протокола в различных микросхемах.
В данной статье будут рассмотрены микросхемы мостов USB‑UART различных производителей, как с точки зрения особенностей поддержки протокола, так и с точки зрения временных/электрических характеристик, а также иных, в том числе не‑электронных соображений.
Производители USB-UART
Есть ряд компаний, для которых мосты USB‑UART являются одним из основных/важных направлений деятельности. Это такие компании, как FTDI, Silicon Labs, Prolific, Cypress (которую недавно купил Infineon), Nanjing Qinheng Microelectronics (владелец бренда WinChipHead), MaxLinear, Microchip. Также существует пара крупных производителей микросхем (Texas Instruments и Maxim Integrated; последнюю недавно купила компания Analog Devices), у которых номинально имеются свои мосты USB‑UART, однако этот вид микросхем не является для них приоритетным.
Линейки мостов USB‑UART первой группы производителей характеризуются:
широким набором корпусов
наличием как медленных и бюджетных (3 Мбит/с и менее), так и быстрых (12 Мбит/с) мостов
тактированием как от внутренних генераторов частоты, так и внешних резонаторов
наличием встроенных регуляторов напряжения (LDO) для понижения 5‑вольтового питания USB до 3,3 В или ниже (обычно документация прямо сообщает, что мощности встроенного LDO хватит только на сам мост)
Мосты второй группы производителей являются, скорее, уникальными изделиями. Так, MAX3349E от Analog Devices является гибридом двух микросхем в одном корпусе: микросхемы физического уровня USB и, собственно, моста USB‑UART. А микросхема TUSB3410VF от Texas Instruments является, по сути, микроконтроллером с модулем USB, а в мост USB‑UART его превращает специальная прошивка от производителя. Её стоимость сопоставима со стоимостью полноценного микроконтроллера, а также требует внешнего тактирования и внешнего питания 3,3 В. Также к данной группе можно условно отнести и различные микроконтроллеры (вроде STM32F070) общего назначения с модулями USB, которые можно программно превратить в мост USB‑UART.
Цена
Сравнение микросхем по цене является не вполне однозначным действием. Так, если использовать в качестве эталона цен только цены дистрибьютора Mouser Electronics, то микросхемы компаний Prolific и Nanjing Qinheng не попадут в таблицу, ввиду того, что они не продаются у данного дистрибьютора. А цена на стоковых площадках вроде ChipMall сильно зависит от количества микросхем в распродаваемой партии и наличия альтернативных предложений.
Другим источником ценовых аномалий являются микросхемы, снимаемые с производства. Так, не рекомендованный для новых разработок мост FT232RL стоит дороже, чем меньший по размерам и в разы более быстрый мост XR21V1410IL16F.
Поэтому таблица сравнения будет следующая:
Корпус
Сравнение микросхем по габаритам корпуса также неоднозначно. При габаритах посадочного места разъёма USB‑B («квадрат») 12×16 мм не так уж и важно, имеет ли микросхема корпус SSOP-20 (7×7 мм) или же QFN-16 (4×4 мм).
Кроме того, микросхема с меньшим корпусом может занять бо́льшую площадь на плате за счёт необходимости установки внешнего регулятора напряжения 5,0 В в 3,3 В, а также кварцевого резонатора. А может и не занять. Так, при использовании микросхемы на плате с ПЛИС, скорее всего, там уже будут шины питания с необходимыми напряжениями, и встроенный регулятор напряжения окажется избыточным. К тому же, ПЛИС сама может оказаться подходящим источником тактовых сигналов для моста.
Более детальный взгляд
В данном обзоре не будут подробно рассматриваться по‑своему интересные мосты, и вот почему:
TUSB3410VF и MAX3349E. При весьма скромных характеристиках скорости, и выбивающегося из общей массы мостов дополнительного функционала, первый мост является рекордсменом по цене, а второй отсутствует в продаже.
FT230XQ и FT2232H.
Мост FT2232H — это очень распространённый и универсальный мост. Помимо UART, данная микросхема поддерживает ещё 7 различных протоколов. И так как среди них есть протокол JTAG, то FT2232H стала ядром для множества программаторов/отладчиков и поддерживается по умолчанию целым рядом популярных программных продуктов, работающих с JTAG.
А FT230XQ примечателен тем, что это самый маленький мост USB‑UART от компании FTDI (QFN‑16, 4×4 мм).
Однако, если рассматривать все мосты компании FTDI, не хватит ни объёма статьи, ни объёма всего цикла. У них слишком широкая номенклатура микросхем. И тем не менее, далее будут рассмотрены два чипа от FTDI.MCP2200‑I/SO и MCP2221A‑I/ML. Мосты компании Microchip — одни из самых медленных из производящихся в настоящее время. Однако определённого внимания заслуживает мост MCP2221A‑I/P. Он самый большой по размерам корпуса (DIP‑14, 19×8 мм).
Для двенадцати различных мостов, включая мост на основе микроконтроллера STM32F070F6P6, будет проведено более детальное сравнение:
Драйверы: CDC и VCP
Рассмотрим ряд моментов, касающихся программной части мостов USB‑UART, а именно драйверов и протокола USB.
Согласно стандарту USB, любое устройство должно быть сделано так, чтобы к моменту подключения линия D+ была подтянута резистором 1,5 кОм к напряжению +3,3 В (несущественное замечание: для режима LowSpeed подтягиваться должна линия D−). Компьютер, обнаружив при подключении устройства, что линия D+ подтянулась, запрашивает у устройства так называемый дескриптор — описание устройства, выполненное в некоторой стандартизованной для всех устройств USB форме. Этот дескриптор, в частности, содержит коды класса и подкласса устройства.
Список классов и подклассов устройств USB является частью стандарта. Он, однако, представляет из себя не столько стройную, последовательную и логичную классификацию, сколько набор исторических шрамов, полученных стандартом в ходе своего развития.
Примеры:
Несмотря на наличие классов «Audio» (код класса 01h) и «Video» (код класса 0Eh) существует класс «Audio/Video Devices» (код класса 10h)
Рекламные щиты вынесены в отдельный класс «Billboard Device Class» (код класса 11h), а, к примеру, ИК‑устройства являются подклассом «IrDA Bridge device», спрятанным внутрь класса «Application Specific» (код класса FEh)
Классы «Miscellaneous» (код класса EFh) и «Application Specific» (код класса FEh), по сути, оба являются разделом «Прочее». Тем не менее оба присутствуют в списке классов вместе со своими подклассами
Имеется отдельный класс «Printer» (код класса 07h), а отдельных классов для клавиатуры и мыши нет. Они вместе со многими другими устройствами помещены в класс «Human Interface Device» (код класса 03h)
Сам класс «Human Interface Device» наделён настолько обширным функционалом, что в него умещаются даже те устройства, которые в принципе с человеком никак не взаимодействуют. Причём производители помещают эти устройства в класс «Human Interface Device», несмотря на наличие такого класса, как «Vendor Specific» (код класса FFh)
Есть расхожее утверждение, что мосты USB‑UART относятся к классу устройств «Communication Device Class» (CDC). Отчасти это так. Правда, с достаточно большим «но!». Если мы взглянем на список подклассов класса CDC…
...то увидим, что здесь нет ничего, напоминающего UART. Если же мы ознакомимся с документом USBPSTN1.2 из колонки «Reference», то заметим две важные вещи:
Данный документ описывает телефонные модемы (PSTN — «Public Switched Telephone Network»)
В самом его конце, в маленьком примечании говорится:
A USB modem may provide means to accommodate common functions performed on a 16550 UART. For more information, see Section 3.2.2.1, “Abstract Control Model Serial Emulation.”
В предыдущей статье цикла была упомянута микросхема PC16550D, крайне популярная в конце 80‑х и реализующая функционал UART‑а. В цитате речь именно о ней.
То есть UART, выросший из телефонных модемов 60‑х годов, к концу 90‑х (когда формировался стандарт USB) не успел от них уйти далеко. И в рамках стандарта стал неким дополнительным функционалом при телефонных модемах. Спустя всего 8–10 лет основной функционал многих подклассов CDC окончательно стал сугубо историческим, но UART‑у уже не отделаться от своего телефонно‑модемного прошлого :)
В частности, это выражается в любопытных артефактах старины
В файле usbd_cdc_if.c из стандартной библиотеки для современных микроконтроллеров STM32, можно встретить упоминание (бездумно скопированное из документа USBPSTN1.2) не только 5...8‑битных, но и... 16‑битных символов:
static int8_t CDC_Control_FS(uint8_t cmd, uint8_t* pbuf, uint16_t length)
{
UART_HandleTypeDef uart_handler;
switch(cmd)
{
case CDC_SEND_ENCAPSULATED_COMMAND:
//
break;
<...> /*******************************************************************************/
/* Line Coding Structure */
/*-----------------------------------------------------------------------------*/
/* Offset | Field | Size | Value | Description */
/* 0 | dwDTERate | 4 | Number |Data terminal rate, in bits per second*/
/* 4 | bCharFormat | 1 | Number | Stop bits */
/* 0 - 1 Stop bit */
/* 1 - 1.5 Stop bits */
/* 2 - 2 Stop bits */
/* 5 | bParityType | 1 | Number | Parity */
/* 0 - None */
/* 1 - Odd */
/* 2 - Even */
/* 3 - Mark */
/* 4 - Space */
/* 6 | bDataBits | 1 | Number Data bits (5, 6, 7, 8 or 16). */
/*******************************************************************************/
case CDC_SET_LINE_CODING:
//
break;
<...>
default:
break;
}
return (USBD_OK);
}
Cтандартный драйвер usbser.sys, управляющий мостами USB‑UART, не загружался автоматически при подключении нового устройства вплоть до Windows 8.1 включительно. В настоящий же момент для автоматической загрузки данного драйвера устройство USB должно сообщить в дескрипторе, что оно относится к классу CDC (код класса 02h) и подклассу Abstract Control Model (код подкласса 02h).
Однако, существует проблема. Производители мостов USB‑UART стремятся наделить их дополнительным функционалом. К примеру, 8‑битным портом GPIO, дополнительными интерфейсами SPI/I2C/JTAG, возможностью сохранить определённые настройки внутри самой микросхемы моста (запрограммировав при этом её через USB) и так далее. Разумеется, весь этот функционал не поддерживается стандартным драйвером usbser.sys. Поэтому производители задают своим мостам класс устройства Vendor Specific (либо Miscellaneous) и выпускают собственные драйверы. Эти драйверы реализуют дополнительный функционал, а также способны создать в операционной системе виртуальный COM-порт (Virtual COM Port — VCP), который с точки зрения приложений работает точно так же, как и COM-порт, созданный драйвером usbser.sys.
В данной таблице есть три строчки, представляющие особый интерес:
STM32F070F6P6. Так как данный микроконтроллер превращается в мост USB‑UART за счёт прошивки, скомпилированной из программного кода, то можно настроить его так, чтобы операционная система предоставляла ему именно стандартный драйвер usbser.sys.
CY7C65213‑28PVXI. Производитель данного моста предусмотрел возможность использования как стандартного драйвера, так и драйвера производителя. Для внесения определённых изменений в реестр и дальнейшего использования usbser.sys производитель предоставляет специальный установочный файл CyWinCDC.inf и инструкцию. Однако производитель предупреждает, что драйвер от Microsoft не позволит развить максимально возможную для данного моста скорость передачи данных и использовать его дополнительные функции.
FT260Q. Данный мост определяется системой как устройство класса HID. С одной стороны, для данного класса имеется стандартный драйвер. С другой стороны, за счёт обширного функционала, которым наделён данный класс, возможно реализовать взаимодействие компьютера с устройствами абсолютно любого назначения. Однако, в силу всё той же разносторонности HID, для эффективного написания прикладного программного обеспечения требуется библиотека LibFT260.dll от производителя. Библиотека является закрытой и в некотором смысле является тем же самым драйвером.
Уместно упомянуть череду скандалов, связанных с драйверами мостов USB‑UART
В 2011 году компания Prolific выложила новый драйвер для своих мостов PL2303 взамен старого. И внезапно мосты разделились на те, что работают с новым драйвером и те, что нет. Prolific утверждала, что это её маленький крестовый поход против контрафактных чипов и напоминала, что только она имеет право распространять свои драйверы. А скачивать их друг у друга или делиться ссылками — незаконно.
Please be warned that counterfeit (fake) PL-2303HX (Chip Rev A) USB to Serial Controller ICs using Prolific's trademark logo, brandname, and device drivers, were being sold in the China market. Counterfeit IC products show exactly the same outside chip markings but generally are of poor quality and causes Windows driver compatibility issues (Yellow Mark Error Code 10 in Device Manager). We issue this warning to all our customers and consumers to avoid confusion and false purchase.
Please be warned that selling counterfeit products are illegal and punishable by civil and criminal courts according to the trademark, copyright, and intellectual properties laws and regulations. Prolific will take proper and severe actions to cease and confiscate these counterfeit products. Prolific also prohibits the distribution of any PL-2303 drivers (including download links) without written permission from Prolific.
В сообществе, правда, появилась и альтернативная точка зрения, что в данном случае имеет место быть попытка «выдать баг за фичу». Что инженеры Prolific потеряли некоторые компетенции в части написания драйверов. А когда, наставив в коде костылей, они наконец запустили новый драйвер и выложили его в публичный доступ, то он самым позитивным (для Prolific) образом отказался работать с контрафактными изделиями.
Как бы то ни было, в 2014 году происходит самый известный случай подобного рода. Компания FTDI выпустила драйвер, который по ряду недокументированных особенностей распознавал контрафактную микросхему и изменял в её встроенной памяти PID — идентификатор продукта из пары VID/PID (Vendor ID/Product ID). В результате микросхема переставала распознаваться не только новым драйвером, но и всеми предыдущими. Хотя подобное действие имело обратимый характер (в сети в скором времени появились инструкции по «раскирпичиванию» мостов FTDI), оно было воспринято сообществом крайне негативно. По некоторым сообщениям, «вишенкой на торте» была попытка протолкнуть данный драйвер в ядро Linux.
Спустя всего два года появились сообщения, что FTDI сделало «второй подход к снаряду». По словам очевидцев, драйвер 2016 года не «окирпичивал» мост, но начинал периодически рассылать случайные символы по линии TX. Ещё пикантней ситуацию делает возможность тихой установки драйверов. Как написано в инструкции FTDI Driver Installation Guide for Windows 10/11:
3 Installing CDM Drivers
To install CDM drivers for an FTDI device under Windows 10/11, follow the instructions below: Connect the device to a spare USB port on your PC.
3.1 Windows Update
If there is an available internet connection, Windows 10/11 will silently connect to the Windows Update service and install any suitable driver it finds for the device.
Назначение выводов
Количество выводов моста USB‑UART, которые должны присутствовать в обязательном порядке, равно шести: линии D+/D− интерфейса USB, линии Tx/Rx интерфейса UART, питание и земля.
Дополнять этот минимальный набор можно достаточно широко. Так, у мостов MCP2221A имеются встроенные аналого‑цифровые и цифро‑аналоговые(!) преобразователи, входы (для ЦАП — выходы) которых можно назначить на выводы моста. В рамках же специфики UART субъективно и претенциозно можно выделить следующие дополнительные выводы:
VREGIN/VREGOUT. Некоторые мосты снабжают регуляторами напряжения 5,0 В → 3,3 В для возможности построения законченного устройства на базе моста без использования дополнительных микросхем питания. Для корректной работы подобных регуляторов, на их входе и выходе должны стоять достаточно большие ёмкости. Поэтому, даже в случае, если шины питания внутренней логики и выходных буферов соединены с выходом регулятора внутри корпуса моста, данный выход всё равно соединяется с отдельным выводом микросхемы, чтобы обеспечить требуемую ёмкость внешним конденсатором. Именно так, к примеру, сделан мост MCP2221A‑I/P. Кроме того, выход VREGOUT в данном мосте называется VBUS, хотя обычно вывод с подобным названием имеет иной функционал.
VI/O. Внутренняя логика мостов работает при фиксированном напряжении питания. Однако для сопряжения моста с максимально возможным количеством типов микросхем без использования дополнительных трансляторов уровня сигнала, в некоторых мостах предусмотрена возможность отдельного питания выходных буферов.
VBUS. Мосты могут применяться в портативных устройствах с питанием от аккумулятора. И напряжение на входе питания моста может присутствовать независимо от того, подключен ли интерфейс USB к устройству или нет. В последнем случае является уместным гарантированное отключение моста с целью сберечь заряд аккумулятора. Вывод VBUS позволяет при помощи резистивного делителя определять наличие напряжения на линии +5 В интерфейса USB и отключать устройство, если этого напряжения на линии нет. Иногда данный вывод устойчив к входному напряжению +5 В и шину питания можно подключать к нему напрямую.
nRST. Позволяет устройству отключить мост при необходимости. Соответственно, если устройство состоит только из моста, данный вывод (как и вывод VBUS) должны быть соответствующим образом подтянуты. В некоторых микросхемах (например, в CH340T этот вывод называется NOS#) имеется внутренняя подтяжка, позволяющая обойтись без подключения данного вывода куда бы то ни было. В других мостах без внешней подтяжки микросхема не запустится. Особенно много внешних подтяжек нужно мосту FT260Q.
OSCI/OSCO. Микросхемы мостов могут иметь как внутренний источник тактирования на основе RC-генератора, так и внешний на основе кварцевого резонатора. В большинстве случаев доступен лишь один из этих вариантов. То есть если данные выводы имеются, они должны быть подключены к кварцевому резонатору (обычно его резонансная частота равна 12 МГц). Иначе мост не заработает. Исключение — FT232RL, у него доступны оба варианта тактирования. Если его выводы OSCI/OSCO не подключены к внешнему резонатору, он автоматически работает от внутреннего генератора. Также, при наличии в устройстве микросхемы, способной выдавать опорный сигнал с подходящей частотой, можно не использовать кварцевый резонатор, а завести этот сигнал на вход OSCI моста USB‑UART.
LED_TX/LED_RX. Данные выводы применяются для индикации передачи и приёма отдельных символов. Выводы работают в режиме open‑drain. То есть когда происходит приём/передача очередного символа, они соединяются с землёй. Если приём/передача не ведётся, то они находятся в состоянии HiZ — отрезаны как от земли, так и от питания. Получается, чтобы светодиоды светили как надо, их необходимо расположить между питанием и данными выводами, катодом («стрелкой») в вывод.
Количество и функционал выводов различных мостов может быть весьма обширен и включать в себя такие дополнительные линии, как RTS/CTS и DTR/DSR. Однако, говоря субъективно и претенциозно, для задачи соединения ПЛИС с компьютером через мост USB‑UART, знание о назначении этих выводов не даст никаких преимуществ перед незнанием.
Временные характеристики: погрешность делителя
Как уже говорилось, документа под названием «стандарт UART», в котором были бы прописаны стандартные битрейты, не существует. Однако некоторым подобием стандарта может служить список констант из заголовочного файла winbase.h для WinAPI:
#define CBR_110 110
#define CBR_300 300
#define CBR_600 600
#define CBR_1200 1200
#define CBR_2400 2400
#define CBR_4800 4800
#define CBR_9600 9600
#define CBR_14400 14400
#define CBR_19200 19200
#define CBR_38400 38400
#define CBR_56000 56000
#define CBR_57600 57600
#define CBR_115200 115200
#define CBR_128000 128000
#define CBR_256000 256000
Мосты USB‑UART получают заданный битрейт путём деления фиксированной опорной частоты тактового генератора. В некоторых случаях формула для вычисления битрейта приводится в документации в явном виде. К примеру, у моста FT232RL битрейт равен:
где «n» — это целое число в интервале от 2 до 16384, а «x» принимает значения от 0 до 0,875 с шагом 0,125.
Если взять «n», равное 312, и «x», равный 0,5, то получится битрейт, строго равный 9600 бит/с. Однако, попытка подобрать делители для другого стандартного битрейта — 115200 бит/с — будет не столь успешной. Ближайшим достижимым значением окажется 115384,6 бит/с. Погрешность кажется небольшой, всего 0,16%. Но она будет накапливаться с каждым битом. И если в символе 8 бит данных, то к последнему биту она составит 1,44%.
Формула вычисления битрейта приводится далеко не для всех мостов. Однако в некоторых случаях можно проследить принцип, по которому это деление происходит. Так, в мостах PL2303TA и CH340T, по всей видимости, имеется фиксированный делитель на 13, подключаемый делитель на 3 и множество D‑триггеров, которыми очень удобно делить частоту на 2. Данный подход создаёт фиксированную погрешность в 0,16% для длительности каждого бита и не позволяет задавать произвольные битрейты. Но он проще с точки зрения схемотехники.
Также, помимо погрешности от деления, на точность битрейта влияет номинал опорного генератора и ряд иных особенностей конструкции мостов. Поэтому уместно будет экспериментально измерить погрешности номинальных значений для стандартных битрейтов.
В таблицах ниже указаны отношения накопленной за весь символ погрешности к длительности последнего бита в процентах для передачи в конфигурации 8N1 (8 бит данных, бита чётности отсутствует, один стоп-бит).
Временные характеристики: случайная погрешность
Помимо систематической составляющей погрешности временных параметров имеется также и случайная, обусловленная погрешностью опорной частоты.
Здесь следует сказать несколько слов про нормальное распределение. Оно характеризуется математическим ожиданием (или иначе говоря, средним значением) и стандартным отклонением. Стандартное отклонение отвечает за уровень разброса значений. Чем оно меньше, тем меньше разброс. Так же, квадрат стандартного отклонения имеет своё собственное название — «дисперсия». Или же дисперсия отвечает за разброс значений, а квадратный корень из неё имеет своё название — «стандартное отклонение».
Если имеется нормально распределённая случайная величина с известным математическим ожиданием μ и стандартным отклонением σ, то можно найти допуск, из которого случайная величина будет выходить с заданной вероятностью. Так, из допуска в μ ± σ нормально распределённая случайная величина выходит с вероятностью 31,74%. Из знаменитого допуска μ ± 3σ — с вероятностью 0,28%. Для вероятности выхода «один-на-тысячу» допуск будет равен μ ± 3,2905σ. Для «один-на-миллион» — μ ± 4,8916σ.
Математическое ожидание суммы двух нормально распределённых величин равно сумме их математических ожиданий, что в целом интуитивно понятно.
Со стандартным отклонением всё несколько сложнее. При суммировании двух случайных, нормально распределённых величин складываются квадраты стандартных отклонений, то есть дисперсии.
В контексте передачи бит, если второй фронт старт-бита «дрожит» с относительным стандартным отклонением σ/T, то фронт N-го бита (если за первый бит считать старт-бит) будет «дрожать» относительно длительности суммы длительностей всех предыдущих битов, как указано в этой формуле:
А относительно длительности последнего бита, последний фронт будет «дрожать» как указано в этой формуле:
Нельзя сказать, что полная вероятность хотя бы одной ошибки в символе по причине «сползшего» фронта в любом из N бит в точности равна вероятности выхода за заданный интервал именно в последнем, N-ом бите. Однако с уменьшением целевой вероятности ошибки, полная вероятность достаточно быстро стремится именно к вероятности выхода из допуска последнего бита. Так, при вероятности ошибки в последнем бите, равной 1×10−3, полная вероятность ошибки будет равна 1,191×10−3.
Рассмотрим реальное распределение длительности символов. Зададим битрейт, равный 1200 бит/с, длину символа — 8 бит, без бита чётности, стоп‑бит — одинарный. Если передать символ, содержащий данные 00h (то есть девять логических нулей, включая старт‑бит) с такими настройками, то номинально линия TX должна оказаться в состоянии логического нуля на 7500 мкс. При этом длительность одного бита будет равна 833,333 мкс. Если с подобными настройками попытаться выдать несколько миллионов символов, к примеру, через мост CH340N, то получится следующее распределение:
Если целевым показателем уровня ошибок будет, например, 1 ошибка на 1012 символов, то допуск по длительности, который необходимо обеспечить, будет примерно ±7σ. Или ±11,77 мкс для данного распределения. Если в процентах от длительности одного бита, то ±1,41%.
Следует, однако, заметить, что реальные источники тактирования мостов далеко не всегда имеют нормально распределённый разброс частоты. Так, распределение длительности символа для моста FT232RL, работающего от внутреннего RC‑генератора, будет иметь характерный пик, торчащий слегка сбоку из «колокола» нормального распределения. Предположительно, данный пик возникает в результате подстройки внутренней системы тактирования моста по синхроимпульсам, идущим в начале каждого пакета USB:
Тем не менее, можно грубо сравнить точностные характеристики систем тактирования мостов, полагая, что частота синхроимпульсов, выдаваемых ими, распределена нормально. Ниже в таблице приведен допуск в процентах от длительности одного бита при уровне ошибок «одна ошибка в год при непрерывной передаче данных и битрейте 9600 бит/с»:
Электрические характеристики
При передаче данных, на стороне ПЛИС мост USB‑UART должен своевременно устанавливать заданные напряжения логического нуля или логической единицы. Если с номинальным напряжением логической единицы всё достаточно прозрачно — данную характеристику можно прочесть в технической документации — то со своевременностью всё несколько сложнее.
Ниже приведены осциллограммы передачи старт‑бита мостами FT260Q и XR21V1410IL16 через двухметровый 50‑омный коаксиальный кабель при скорости 12 Мбит/с. Также осциллограммы передачи старт‑бита мостами PL2303TA и FT232RL через тот же кабель при скорости 3 Мбит/с.
Налицо проблемы с согласованием импедансов (подробнее о согласовании вот в этом цикле), которые вполне способны привести к ошибкам в передаче данных. Хотя на реальной плате импеданс дорожек будет ближе к 100 Омам (то есть чуть ближе к выходному сопротивлению выходных буферов данных мостов), а длина в разы, а то и на порядки меньше, тем не менее в отдельных пограничных случаях рассогласование может сыграть свою негативную роль.
Как видно на графиках, для некоторых микросхем выходное сопротивление будет сильно различно для восходящего и нисходящего фронта. Соответственно, выбор импеданса дорожки станет компромиссом. Подобное различие объяснимо структурой выходного буфера, который условно можно считать логическим элементом НЕ. В таком буфере за восходящий и нисходящий фронты отвечают транзисторы разных типов проводимости (NMOS и PMOS) и их характеристики могут значительно отличаться.
Наиболее полно вольт-амперные и временные характеристики выходных буферов приводятся в моделях IBIS (подробнее о моделях IBIS и том, как ими пользоваться вот в этой статье). Однако корректное снятие показаний для этих моделей является дорогостоящим процессом, за результаты которого (даже в случае предварительного отказа от последствий) так или иначе компания‑производитель несёт репутационную ответственность. Поэтому далеко не все производители предоставляют модели IBIS.
Тем не менее, возможно замерить некое усреднённое значение внутреннего сопротивления выходного буфера, которое окажется полезным, если не для точной симуляции, то хотя бы для качественной оценки согласования на реальной плате.
Оверсемплинг и коррекция ошибок
Традиционно, оверсемплинг, как характеристика приёмника сигнала UART, указывается только для модулей UART в микроконтроллерах. Соответственно, из всех исследуемых мостов данная характеристика указана лишь для STM32F070. Однако оценить оверсемплинг и, в целом, принцип работы приёмника UART, возможно при помощи специальных тестовых сигналов.
Представим, что приёмник UART исследуемого моста имеет 8-кратный оверсемплинг, а логическое значение бита фиксируется на четвёртом семпле. Допустим, возможно осуществить передачу битов символа UART с точностью временны́х параметров значительно большей, чем временная точность исследуемого моста. И в рамках этой передачи можно сформировать тестовый импульс, длительность которого меньше, чем длительность бита. Причём сам импульс можно произвольно сдвинуть относительно начала бита.
Если тестовый импульс не пересекается с временным интервалом от 3T⁄8 до 4T⁄8 (где T — длительность бита), то он не будет считан приёмником UART. Если тестовый импульс полностью накрывает указанный интервал, то только тестовый импульс и будет влиять на считываемое значение. Если же импульс перекрывает данный интервал частично, то шанс, что приёмник прочитает не логическое значение бита, а логическое значение тестового импульса будет пропорционален отношению длительности перекрытия к длительности 1⁄8 бита.
Зафиксируем длительность тестового импульса и «пробежимся» импульсом по биту. То есть будем сдвигать импульс на небольшой интервал времени и при каждом новом смещении многократно снимем данные, которые получает приёмник UART. Получаемые данные будем усреднять. Если при определённом значении смещения из 100 замеров 46 показали значение тестового импульса, то данному смещению мы присвоим показатель считываемости 46%. Затем построим график, где аргументом будет смещение, а значением — считываемость.
По длительности наклонных участков данного графика будет несложно установить значение оверсемплинга приёмника.
Рассмотрим подобные графики для трёх различных мостов с тремя длительностями тестового импульса для каждого:
По графикам, относящимся к тестовому импульсу с длительностью 8T⁄32, возможно определить, что у приёмников моста FT232RL и моста на базе STM32F070 16‑кратный оверсемплинг. А у приёмника моста CP2102N его кратность во много раз больше.
Кроме этого, по графикам видно, что считывание бита у FT232RL происходит по восьмому семплу — вторая наклонная часть графика сдвинута влево относительно середины. А у моста на базе STM32F070 она сдвинута вправо, потому что средним семплом в мажорирующей группе (на рисунке ниже она обозначена как sampled values) является девятый семпл. Да, при чётном количестве семплов, «центральный» семпл бита придётся выбрать из двух возможных вариантов произвольным образом.
На графиках, относящимся к тестовым импульсам с длительностью 3T⁄32 и 1T⁄32 , видна работа системы коррекции ошибок приёмника USART (в документации на микроконтроллеры STM32 он пишется именно через «S») микроконтроллера STM32F070. Импульс, длительностью короче, чем 1T⁄16 однозначно воспринимается данной системой, как помеха в линии, тогда как другие мосты вполне способны принять такой импульс за значение очередного бита.
Любопытными являются графики моста‑антирекордсмена CH340N, имеющего 4-кратный оверсемплинг:
Если свести результаты исследований всех мостов USB‑UART в таблицу, результат будет следующий:
Наличие коррекции ошибок у моста FT260Q является спорным вопросом. С одной стороны, тестовый импульс короче, чем T⁄2, не будет считан приёмником данного моста. С другой стороны наличие короткого тестового импульса в ряде случаев вызывает изменение последнего бита символа. Связано ли подобное поведение с работой системы коррекции ошибок, либо это какое‑то недокументированное поведение микросхемы, которое разработчики не планировали закладывать в данный мост, — сказать сложно.
Количество бит
Традиционно, количество бит в символе UART составляет от 5 до 8. Затем опционально может идти контрольный бит. А затем 1/1,5/2 стоп‑бита.
Рассмотрим, к примеру, мост MCP2221A, который поддерживает только 8‑битные символы без бита чётности и со строго одним стоп‑битом (конфигурация 8N1). Мы, безусловно, можем передать с помощью данного моста 5‑битный символ просто наложив маску единиц на последние три бита 8‑битного символа. Также мы могли бы принять те 5‑битные символы, задержка между которыми составляет 4 и более битовых интервалов времени. Однако непрерывный поток 5‑битных символов, разделяемых лишь одним стоп‑битом, принять мостом MCP2221A не удалось бы в любом случае.
Несмотря на то, что 5‑битные и 6‑битные символы UART являются абсолютной архаикой, компании Silicon Labs, Prolific и Nanjing Qinheng стойко чтут традиции:
С 7‑битными символами ситуация иная. Не молодой, но вполне активно используемый протокол Modbus задействует их в своей работе.
Здесь, однако, есть нюанс. Значительная часть оборудования Modbus не использует 7‑битные символы без контрольного бита с одним стоп‑битом. То есть или 7 бит без контрольного бита, но с двумя стоп‑битами (7N2); или 7 бит с одним стоп‑битом, но обязательно будет контрольный бит (7E1/7O1); или без контрольного бита и с одним стоп‑битом, но уже 8 бит (8N1).
Поэтому регистр данных модуля USART микроконтроллера STM32F070, рассчитанный только на 8/9 бит, способен эффективно работать с 7‑битными символами Modbus. Либо модуль USART добавляет единицу (стоп‑бит) к 7 битам и задаёт конфигурацию 7N2, либо добавляет контрольный бит и задаёт конфигурацию 7E1/7O1. Аналогично, в теории, 7‑битные символы Modbus мы вполне могли бы принять при помощи MCP2221A и последующей обработки.
Как упоминалось в предыдущей статье цикла, UART‑подобный стандарт MDB использует 9‑битные символы. Они не содержат контрольного бита и имеют один стоп‑бит (конфигурация 9N1). Очевидно, одного байта данных, пришедшего от USB, не хватит, чтобы заполнить битами такой символ. Поэтому данный режим использует в своей работе пару байт.
Среди исследуемых мостов подобную конфигурацию могут реализовать только XR21V1410 и STM32F070. С последним всё более‑менее объяснимо — как мы его запрограммируем, так он и будет выдавать/принимать данные. А вот поведение XR21V1410 жёстко задано производителем.
Документация весьма скупо описывает процесс настройки режима 9N1 у XR21V1410. А техническая поддержка производителя отмалчивается. Однако данный режим возможно включить путём заполнения поля ByteSize структуры DCB числом 9, инициализации COM‑порта через функцию SetCommState и передачи в устройство магического кода 0x22205C:
#include <windows.h>
int main()
{
HANDLE hUart;
CHAR uartName[] = "\\\\.\\COM30"; //номер COM-порта, присвоенный XR21V1410
hUart = CreateFileA(uartName, GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
DCB uartDCB;
uartDCB.BaudRate = CBR_9600;
uartDCB.ByteSize = 9;
uartDCB.Parity = NOPARITY;
uartDCB.StopBits = ONESTOPBIT;
SetCommState(hUart, &uartDCB);
DeviceIoControl(hUart, 0x22205C, (LPVOID)NULL, 0, (LPVOID)NULL, 0, (LPDWORD)NULL, (LPOVERLAPPED)NULL);
const UINT16 arrayLen = 2;
UINT8 array[arrayLen];
array[0] = 0x33; //данные с 1 по 8 бит
array[1] = 0x01; //9 бит, 0x01/0x00
WriteFile(hUart, array, arrayLen, (LPDWORD)NULL, (LPOVERLAPPED)NULL);
CloseHandle(hUart);
return 0;
}
Заключение
Мосты USB‑UART весьма разнообразны и практически из любого правила, из любого обобщения вида «любой нормальный мост USB‑UART», будет то или иное исключение.
Если же всё‑таки попробовать субъективно и претенциозно обобщить характеристики, то типичный мост USB‑UART будет выглядеть так:
Стоит в розницу чуть меньше 2,5 долларов за штуку
Имеет корпус SSOP‑20
Требует наличия драйвера производителя
Имеет: внутренний регулятор напряжения, выводы для индикации активности приёма/передачи, работающие в режиме open‑drain; и вывод nRST, отключающий мост
Также, он имеет внутренний источник тактового сигнала
Поддерживает стандартные (де‑факто) битрейты от 1200 до 115200 бит/с...
...которые выдерживает в самом худшем случае с точностью около 1,0%
Помимо стандартных битрейтов, поддерживает скорость порядка 3 Мбит/с
Выходное напряжение логической единицы составляет 3,3 В
Выходное сопротивление примерно равно 100 Омам
Имеет, как минимум, 16‑кратный оверсемплинг
Не производит коррекцию ошибок в рамках одного бита
Поддерживает 7‑битную и 8‑битную длину символов
Поддерживает один либо два стоп‑бита
Комментарии (43)
aabzel
03.08.2023 09:52+2Поддерживает один либо два стоп‑бита
Зачем два стоп-бита UART, если с одним стоп битом больше плотность данных?
datacompboy
03.08.2023 09:52+3Дать время успокоиться каналу между пакетами, например для длинных линий.
datacompboy
03.08.2023 09:52+5Кстати о птичках. Насколько я помню, второй стопбит обычно воспринимается исключительно как пауза для передатчика, зачастую приёмник 8N1 от 8N2 не отличает.
Если очень хочется контролировать, то можно использовать 8M1 (когда бит четности ставится в 1цу) (если UART поддерживает, конечно же)
Flammmable Автор
03.08.2023 09:52+2Предположим, имеется классическая ATmega328P и требуется выжать из неё максимальную пропускную способность. Напрашивающимся решением является повысить битрейт на столько, на сколько это возможно. Битрейт в данных МК определяется делителем UBRR. Чтобы выжать из ATmega328P максимальный битрейт необходимо понизить делитель частоты UBRR как можно ниже. Но. При низких значениях UBRR его изменение будет весьма резко изменять битрейт.
При UBRR равном двум, битрейт будет равен f/16.
При UBRR равном трём, битрейт будет равен f/32.
При UBRR равном четырём, битрейт будет равен f/48.
Теперь представим, что символы приходят непрерывным потоком. При максимальном битрейте и символе 8N1 у ATmega328P будет 16 тактов между символами, чтобы обработать очередной символ. Если на обработку требуется, скажем, 20 тактов, то понижение битрейта понизит пропускную способность на 50%. А добавление ещё одного стоп-бита понизит её всего на 11%
Справедливым является вопрос: так ли уж надо обрабатывать очередной символ сразу же после его прихода? Не проще ли его скопировать в память, 16 тактов на это должно хватить, а затем обрабатывать столько, сколько идёт следующий символ? Да, проще - если данные между устройствами передаются длинными пакетами. Но если имеется подобие адресации (одно устройство передало один символ с адресом некоего регистра, второе - передаёт/возвращает данные из этого регистра) то в предельном случае такая конфигурация "отъедает" 33% пропускной способности (один символ - туда, один символ - ожидание/обработка, один символ - обратно). И тогда потеря 11% будет более предпочтительна.
На мой взгляд, субъективный и претенциозный, двойной стоп-бит - это архаика и экономия на спичках в ущерб единообразию.
Но я с интересом прочитаю любое другое объяснение применимости двойного стоп-бита, если оно будет обосновано весомыми аргументами.Rusrst
03.08.2023 09:52+1Не обязательна даже адресация, если что-то на лету считается например (та же CRC) то уже могут быть проблем. Плюс 16 тактов объективно мало - не все команды все же за такт работают. Плюс что там компилятор сделает не известно.
Flammmable Автор
03.08.2023 09:52Всё, что приходит по Rx, теоретически, можно буферизировать и ковыряться с ним весь следующий символ. Какая разница, выявит CRC сбой за паузу между символами или выявит в течение следующего символа? Всё равно - перепосылать.
Так что у операций между символами должно быть дополнительное, внешнее обоснование.
Rusrst
03.08.2023 09:52Можно что угодно делать, но 16 тактов мало, а буферизация не всегда возможна - у мег, 1 КБ памяти, много туда набуферизируешь если МК не только с UART работает?
Flammmable Автор
03.08.2023 09:52Забуферизировать надо только один символ.
datacompboy
03.08.2023 09:52Так UART сам буферизирует 1 символ, даже на 8051, разве нет?
Но буферизация одного символа не помогает, так как через 16 тактов уже следующий символ и затем следующий. То есть тактика работает если можно в 32 такта уложить обработку двух но в 16 одного нет.
Либо я не понимаю о чем идет речь :)
Я в 8051 порой вынужден был потратить 256 байт кода под табличку для упаковки обработки принятого символа чтобы hex2bin и bin2hex делать со всеми проверками максимально дёшево по тактам и ОЗУ -- и использовать буфер половинного объёма, основной поток мог обрабатывать медленно не задерживая коммуникацию в кольце вообще
Flammmable Автор
03.08.2023 09:52По завершению приёма символа копируете за 16 тактов данные из регистра данных USART в однобайтовый буфер ОЗУ. И дальше работаете с символом в однобайтном буфере ОЗУ 16х8 (для 8N1) тактов. Тем временем следующий символ считывается в регистр данных USART.
datacompboy
03.08.2023 09:52Стоп. Мы говорим о 16 тактов на БИТ а не 16 тактов на БАЙТ?
Flammmable Автор
03.08.2023 09:52О 16 тактах на бит. При 16 тактах на байт добавление/убавление второго стоп-бита погоды не сделает ни в каком случае.
datacompboy
03.08.2023 09:52ATmega328P будет 16 тактов между символами
Тогда вообще не складывается. У меги 1 буфер байт + байт который собирается (или это просто 2 байта буфер? давно трогал её). То есть у нас всегда есть время в полный байт на то чтобы забрать байт из входного регистра и свободить его для следующего.
В какой ситуации берётся требование что-то сделать строго за стоп-бит?
Flammmable Автор
03.08.2023 09:52Гипотетически, такое требование может взяться из необходимости моментального ответа на пришедший байт. Но это мой, несколько надуманный пример, чтобы оправдать наличие двойного стоп-бита.
К слову, не совсем понял ваш пост про
Дать время успокоиться каналу между пакетами, например для длинных линий.
Если линия согласована, то нечему в ней успокаиваться.
Если линия не согласована, да так, что это мешает передаче, то по какой причине её не согласовали?
В любом случае, двойной стоп-бит от этого точно не поможет.
datacompboy
03.08.2023 09:52Гипотетически, такое требование может взяться из необходимости моментального ответа на пришедший байт. Но это мой, несколько надуманный пример, чтобф оправдать наличие двойного стоп-бита.
Логично, но тогда непонятно чем второй стопбит изменит ситуацию -- мы просто меняем шило (разрешение в N бит паузы перед ответом) на мыло (1 бит к каждому входному байту всегда). Но теперь я идею понял :)
Если линия не согласована, да так, что это мешает передаче, то по какой причине её не согласовали?
Да, терминатор на конце линии помогает лучше всего для гарантии. Второй стопбит, который почти все приёмники игнорируют, даёт время избавиться от "звона" от передачи. Для передачи с большим количеством пауз (длинных последовательностей единиц) вообще это никак не помогает, а эксперименты которые мы проводили показывали что 8n2 эффективно подавляет "левый" приём на стороне компа при использовании телефонного кабеля и COM<=>(токовая петля) конвертера. (по осцилографу там всплески где-то в 5% амплитуды были, который MAX радостно конвертировал в нечто более высокое, которое комп распознавал за старт)
При переходе на USB адаптеры лет 10 назад оно осталось уже в форме legacy. Наверное, интересно было бы перепроверить -- есть ли еще польза какая от второго стопа или нет :) Но у меня нет сейчас лабы под руками.
Flammmable Автор
03.08.2023 09:52Я просто понять не могу, допустим есть некое отражение, которое за один стоп-бит не успокаивается, а за два стоп-бита успокаивается. Ну ок. Стоп-биты теперь распознаются. Но в "теле" символа будет белиберда как ни крути. Если мы передаём символ 00010000, то мы точно так же получим на принимающей стороне 00011000 или 00010100 из за отражений.
datacompboy
03.08.2023 09:52Во время передачи, передатчик довольно эффективно давит отражения, успешно как подтягивая вверх так и утаскивая вниз. После передачи он отцепляется от линии возваращя туда приёмник, в итоге на линии становятся все приёмники, то есть никто линию никуда тянет -- и шум начинает влиять. И да, я не думаю, что проблема проявляется на связи точка-точка.
mea culpa, условия в которых проблема встречается, следовало сразу определить...
VT100
03.08.2023 09:52Мне кажется, где-то
в коде закралась ошибкапроизошло неявное преобразование типа тактов. От тактов основного генератора (которые для AVR и лучших представителей MCS-51 равны времени выполнения команд) к тактам блока USART (которые, в общем случае, в N=2<sup>M</sup> раз длиннее).
garus_ru
03.08.2023 09:52+2Ну, например, Modbus использует 11 бит:
1старт + 8бит_данных + 1четность + 1стоп (8E1, как обязывает стандарт поддерживать по умолчанию)
либо
1старт + 8бит_данных + 2стоп (8N2, как дополнительная возможность).
А вообще, скорее всего, чтобы не копить ошибку, связанную с неточностью битрейта. У приемников многих микросхем нет настроек на 2 стоп-бита, а только на один. Стало быть, второй стоп-бит - как пауза в посылках. И каждая новая посылка начинает тактироваться "с чистого листа".
Astroscope
03.08.2023 09:52+2RTS/CTS и DTR/DSR
В моей любительской практике наличие процитированного довольно критично, потому что используется в качестве GPIO для управления внешними устройствами. Конкретный пример: любительская радиостанция, которая по UART получает/отдает основные данные для управления собой и отчета о состоянии, вроде установки частоты и режима работы, независимо использует линии RTS и DTR для переключения прием/передача и FSK (радиотелетайп) манипуляции. Соответственно, поддержка этих линий отладочными платами более чем интересна, хоть и немного выходит за рамки голого UART, вторгаясь уже в RS-232.
Flammmable Автор
03.08.2023 09:52+2Хотел бы отметить. Среди рассматриваемых мостов:
у CH340N в корпусе SOP-8 есть только RTS (очевидно в SOIC-8/SOP-8 физически не засунуть сразу все RTS/CTS/DTR/DSR)
у PL2303GL в корпусе SOP-8 после раскидывания шести обязательных выводов D+/D-/Tx/Rx/Vin/GND на оставшиеся два свободных инженеры повесили выход LDO и Vddio
у MCP2221A несмотря на то, что выводов хватает, нет ни одного вывода из RTS/CTS/DTR/DSR
у CP2102N-A02-GQFN20 есть RTS/CTS, но нет DTR/DSR
И мне любопытно, в тех любительских радиостанциях, о которых вы говорите, наличие у моста выводов RTS/CTS/DTR/DSR является обязательным или опциональным? То есть возможно ли управлять данными радиостанциями при помощи исключительно команд, передающихся через Tx?
В любом случае, я осознаю, что в индустрии имеется оборудование, которое в силу исторических причин требует наличия данных выводов. Однако, по моему субъективному и претенциозному мнению, в новом, проектируемом оборудовании от использования данных линий стоит отказываться.
Соответственно, поддержка этих линий отладочными платами более чем интересна, хоть и немного выходит за рамки голого UART, вторгаясь уже в RS-232.
Тут ещё как знать, кто более голый: UART, у которого отсутствует формализованный стандарт (UART - это просто набор традиций) или RS-232, который содержит электрические параметры, размеры разъёмов и наименование выводов, но не содержит ни правил передачи, ни стандартных битрейтов, ни стандартных длин символов :)
VT100
03.08.2023 09:52+2Возможность минимального квитирования (RTS/CTS) считаю весьма полезной.
Flammmable Автор
03.08.2023 09:52Если говорить о передаче данных в узком смысле, то современный UART в большей мере является протоколом передачи команд и в меньшей - протоколом передачи данных (в смысле, большого объёма однородных данных - видеопотока, скажем).
Да, есть ситуации, когда определённые команды временно не возможны к исполнению устройством. Воображаемый пример: нельзя выполнять команду раскручивания аэростатического подшипника, если в него не подано достаточное давление. Если мы по Tx подаём подряд команды "подать давление в пневматику" и "раскрутить подшипник", то было бы разумным получить по Rx в ответ на вторую команду код ошибки - почему команда "раскрутить подшипник" не может быть сейчас выполнена. Объявление неготовности устройства через CTS здесь кажется более чем неуместным.
Если мы говорим о передаче потока данных, то, положа руку на сердце, можете ли вы сказать, что сейчас есть устройства, которые могут не успеть как-то там переварить данные от потока 9600 бит/с так, что придётся его временно останавливать? Да и даже 12 Мбит/с. Я пытаюсь, но не могу придумать ни класс таких устройств, ни хотя бы какое-то уникальное устройство. Если вы назовёте пример, пусть даже и умозрительный, мне будет весьма любопытно его прочитать.
При этом исторически, назначение подобных выводов более чем понятно. Когда нужно было переливать, скажем, 115200 бит/с в 9600 бит/с и наоборот, тут без квитирования никак. Да, UART вырос из модемов. А для модемов подобный функционал - RTS/CTS - более чем полезен. Но это всё в прошлом.
old_merman
03.08.2023 09:52Но это всё в прошлом.
Пример из личного опыта годовой давности: сливал через USB-UART адаптер на скорости 115200 дамп прошивки с Xiaomi-вской рации на комп, командами встроенного в прошивку рации терминала. Так вот, совершенно для меня неожиданно, оказалось, что при передаче блоков более определённой длины, данные портятся со 100% вероятностью, причём длина эта для разных USB-UART отличается: для адаптеров на "китайцах" ch340, pl2303 ошибки возникали, когда длина блока превышала ~40 байт, для ft232rl - ~1К байт; полное впечатление, что при заполнении внутреннего буфера адаптер какое-то время тормозит, а передатчик продолжает отсылать данные - и часть этих данных благополучно теряется. Была бы возможность у приёмника на время раздумий снять CTS - не было бы никаких проблем, да только вот у рации TXD/RXD есть а CTS/RTS нетути... пришлось написать скрипт который дамп кусочками по 16 байт снимает.
datacompboy
03.08.2023 09:52И у FTDI и у CP были флаги в реестре которые позволяли поднять частоту поллинга. Если моя память не подтекает, то у FTDI дефолт около 15мс. Я снижал до 3-5мс чтоб получить стабильную связь на больших скоростях с минимальными задержками.
https://www.ftdichip.com/Support/Knowledgebase/index.html?settingacustomdefaultlaten.htm
16ms дефолт. На 1-2 становилось хуже, а на 3-5 сильно лучше при обмене
old_merman
03.08.2023 09:52Флаги в реестре полезны там где есть реестр :)
Но вообще спасибо, не знал. Пригодится!
datacompboy
03.08.2023 09:52+1На линуксе тоже: https://granitedevices.com/wiki/FTDI_Linux_USB_latency
А, там еще крутилка размера USB буфера, которая может потребоваться для получения стабильных бОльших скоростей. Я редко выше 57600 использовал, поэтому размер буфера не крутил
vvzvlad
03.08.2023 09:52+4У платок на esp DTR/RTS это практически стандарт для сброса и включения режима программирования.
За статью спасибо, монументально.
Flammmable Автор
03.08.2023 09:52+1Вот за это я и не очень люблю все эти дополнительные линии как в статьях, так и в практике:
Сначала долго разбираемся в их штатном функционале.
Затем внезапно понимаем, что штатный функционал глубоко историчен.
Начинаем использовать их как GPIO0 и GPIO1 для абсолютно произвольных назначений. Но только без IO - либо "I", либо "O".
А когда нам требуется GPIO2, понимаем, что GPIO2 взять неоткуда и этот функционал всё равно нужно реализовывать поверх символов UART-а.
Я осознаю, что желание стройности, унификации и единообразия - это определённый снобизм и что почти все стандарты изрезаны временем, временными наколеночными решениями, которые стали чем-то на редкость постоянным. Но. Веет от этих дополнительных линий RTS/CTS/DTR/DSR брючным ремнём, накинутым на валы взамен лопнувшей штатной ременной передачи :)
За статью спасибо, монументально.
Приятно слышать!
vvzvlad
03.08.2023 09:52+1Мне тоже не нравится, особенно это логическая конструкция на транизсторах, сделанная для обхода обычного поведения DTR/RTS, как я понимаю.
Мы у себя просто взяли IO-линии на FT-что-то-там, где два порта, и второй порт сконфигурировали как GPIO, им и рулим.
Astroscope
03.08.2023 09:52+2И мне любопытно, в тех любительских радиостанциях, о которых вы говорите, наличие у моста выводов RTS/CTS/DTR/DSR является обязательным или опциональным?
Обмен данными, неважно - аппаратно это уровни TTL или RS-232, использует, где я знаю, только RXD, TXD и GND. Дополнительные линии используются для манипуляции логическими уровнями вне. Однако, физически, они предполагаемая часть полноценного коммуникационного порта и софт, управляющий радиостанций, пишет или читает уровни дополнительных линий в дополнение. Мосты же часто оказываются неполноценными в части поддержки хотя бы нескольких линий сверх RXD, TXD и GND.
То есть возможно ли управлять данными радиостанциями при помощи исключительно команд, передающихся через Tx?
В некоторых невозможно, в смысле не поддерживается такая команда в принципе, и во всех нежелательно из-за задержек. Манипуляция логическим уровнем работает быстрее и надежнее, поскольку не тратит время на формирование команды, ее отправку, обработку получателем, ну и значительно меньше подвержена сбоям. Все-таки радиостанция - это источник RFI, а значит риски помех самой себе у нее выше среднего. С дискретным логическим уровнем все сильно проще.
В любом случае, я осознаю, что в индустрии имеется оборудование, которое в силу исторических причин требует наличия данных выводов. Однако, по моему субъективному и претенциозному мнению, в новом, проектируемом оборудовании от использования данных линий стоит отказываться.
В моем примере - едва ли отказ от этих линий оправдан и произойдет кого-то в ближайшем будущем. Пока я вижу тенденцю переносить мост внутрь радиостанции, которая теперь подключается бытовым USB кабелем, но сохраняет и выведенный наружу RS-232 или TTL для совместимости с более старым внешним оборудованием. Естественно, нужно рассматривать конкретные модели, но в среднем где-то так.
Тут ещё как знать, кто более голый: UART, у которого отсутствует формализованный стандарт (UART - это просто набор традиций) или RS-232, который содержит электрические параметры, размеры разъёмов и наименование выводов, но не содержит ни правил передачи, ни стандартных битрейтов, ни стандартных длин символов :)
Вот это вы снова правильно говорите. В моем примере аппаратные различия, в основном, касаются именно уровней - или полный размах, или TTL. Ну а как передаются команды - это у каждого производителя своя несовместимая логика.
VT100
03.08.2023 09:52+2nRST. Позволяет устройству отключить мост при необходимости.
КМК - надо поправить формулировку. "Отключить" - можно понять как "Понизить энергопотребление до мыслимого минимума". А сброс - совсем не про это.
Вообще - шикарно! Спасибо! Виртуальный второй плюс в карму.
dlinyj
Очень подробный и ценный обзор, снимаю шляпу.
Мне не хватило в этой статье ключевых характеристик микросхем: как они относятся к дребезгу земли. Многие дешёвые микросхемы зависают, если идут помехи по земле, в силу плохих контактов. Именно поэтому я больше всего люблю FT232RL, не смотря на её цену, что она стабильно работает даже при самых плохих контактах.
Flammmable Автор
Если расскажете про то, как можно было бы максимально корректно оттестировать этот аспект, то может быть (когда-нибудь) я дополню данную статью и таким исследованием. Платы у меня есть, микросхемы есть, почему бы и не? :)
Fox_exe
Как вариант - протестировать на устойчивость к внешнему воздействию (наводки от трансформаторов и других высоковольтных или высокочастотных элементов устройства).
Просаживание напряжения сигнала
Добавление шума в сам сигнал (имитация плохого контакта и, опятьже, наводок)
Тест на заявленную термоустойчивость...
В общем - тесты на работу в экстремальных и не очень стандартных условиях.
dlinyj
Это тянет на хорошую научную работу, даже сложнее чем просто статья на хабр.
dlinyj
Я не могу придумать как качественно протестировать, разве что вручную отключать-подключать землю и так чтобы оба прибора питались от отдельных блоков питания и не имели общей земли (опасный эксперимент, на самом деле). Но прям конкретных советов не дам.
Я сталкивался с тем, что всякие PL2303 легко зависают из-за дребезга, и приходится перезагружать физическим отключением. Даже китайские FT232RL справляются с этим.
VT100
Тут надо ещё отделить ситуацию "завис хост", которая имеет отличную от нуля вероятность.
dlinyj
Имеет, но чаще глючат микрухи. Это проверяется отсоединением от хоста и перемыканием RX-TX, проверку на эхо. Эха нет.
Flammmable Автор
Хочу отметить, что когда я начинал писать данную статью, FT232RL числился в базе Маузера, хоть и с пометкой "нет в наличие". А сейчас его даже в базе нет. Похоже, NRND - не фигура речи и FTDI взяли решительный курс на сворачивание производства чипа-легенды.