Comments 33
Да, с разъёмами просто беда. Жаль, не устаканился какой-нибудь мелкий коаксиал, мама TX и папа RX на расстоянии 2.5 радиуса от центра до центра. И никаких там «прямых» или «кросс» кабелей — мама всегда источник (розетка), папа всегда приёмник (вилка). И на кабеле, и на корпусе.
Ну и на случай питания можно какой-нибудь пин между ними предусмотреть. Если торчит — устройство нуждается в питании, если там отверстие — может дать +12В (это всё «например», просто как мысли вслух). И на питающем кабеле всегда с одной стороны пин, с другой отверстие. То есть если оба прибора нуждаются в питании, их не соединить, а если оба обеспечивают питание — получается отверстие напротив отверстия, без риска соединения линий питания и возникновения уравнивающих токов.
Почему коаксиал? А ваш покорный слуга любит побаловаться мегабодными компортами :-D
Так зарождался USB
Ваши слова бы Бо… машине времени в уши :) Если бы USB действительно так зарождался, скольких бы проблем со всякими OTG и асимметрией бы избежали… но нееет, стая бежит со скоростью самого медленного члена, а консорциум имеет интеллект самого глупого участника, поэтому в эпоху, когда даже в LPT осознали глубину ошибки и отказались от асимметрии, эти шедевральные, музейные умы родили асимметричный протокол с асимметричными кабелями. Я просто верещу от смеха, как хомяк (молодёжн. «ору в голосину»), когда вспоминаю, как на их глазах LPT переходил к симметричным режимам и каялся, как люди соединяли компы LPT LapLink-кабелями, но эти гении вредительской деятельности «презрительным окинули оком творенья Бога своего, и на челе их невысоком не отразилось ничего».
А зоопарк вольтажей можно было бы разрулить разными диаметрами питающих пинов, кстати.
А зоопарк вольтажей можно было бы разрулить разными диаметрами питающих пинов, кстати.
Чтобы еще больше было проводов, как у ноутбуков? Нет, спасибо. Type-C это пока лучшее, что случилось с юсб и его питанием.
Да. Это для симметричного ком-порта имеет смысл разные диаметры или отдельную линию для «договорёнок», потому что он не подразумевает стандарта в плане того, какими именно данными обмениваться — всё тёпло-лампово-сырое, побайтное (кстати, с нормальными кварцами и два байта можно между стартом и стопом уложить…)
А для USB лучше, действительно, просто кидать спец-пакет, какие нужны напряжения и токи (и какие есть). Если там хаб — то по итогу опроса всех, кто подключен. И даже если бы хватило ума не делать асимметрию, это бы не помешало — наоборот, помогло бы легче договориться, кто кого кормит в случае, скажем, телефона.
Так что согласен.
Насчёт разных диаметров питающих пинов... Было бы, как с Type C :)
Hidden text
вполне качественная статья, единственное возможно стоит подчеркнуть что протокол full duplex, также было бы полезно четко указать разницу между синхронными и асинхронными протоколами (включая UART), типа преимущества и недостатки, это не сложно, для понимания полезно, исторически UART это интерефейс PDP-1, разработан Gordon Bell (DEC)
Кстати, о дуплексе. Когда я колхозил передачу максимума данных по тому же кабелю, я слегка проработал вариант «временного реверса линии»: устройство, гарантированно знающее, что некоторое время ему ничего не придётся передавать, передаёт по Tx специальную команду на реверс, после чего переключает его из Tx во второй Rx (то есть подключает по факту ко второму порту). И после этого может принять посылку фиксированной длительности, если второму устройству есть чего сказать в таких количествах, что по одной линии не пролезает за нужное время. После окончания такого реверса может делать всё как обычно — как правило, скинуть контрольную сумму всего принятого.
Зачем вообще нужны варианты длительности стоп-бита, отличные от 1?
Во многих микроконтроллерах есть режимы UART с 16 выборками на бит, и с 8 выборками на бит <...> Почему считается, что х8 хуже?
Количество 8...16 выборок - это количество выборок оверсемплинга. Оверсемплинг противостоит ошибкам, связанным с временными параметрами. Он позволяет выставить главное, так скажем, считывание как можно более близко к центру бита. Если он - 8, то сдвиг будет не более, чем на 1/8 периода. Если он - 16, то не более, чем на 1/16. В первом случае, если соседний фронт съедет на 37,5% от длительности бита, то будет ошибка, если меньше, то не будет. Во втором случае фронт для возникновения ошибки должен съехать на 43,75%. Выше поднимать оверсемплинг нет смысла, потому, что если фронт съехал на 50% и более - любой оверсемплинг не спасёт.
Ведь в случае длительной помехи система мажорирования трёх центральных выборок с большей вероятностью выдаст правильный результат.
Мажорирование - это попытка незаметно убрать ошибки. С некоторой вероятностью это приводит к, так скажем, заметанию ошибок под ковёр. Есть мнение, что не нужно ожидать, пока "мажорирование <...> с большей вероятностью выдаст правильный результат", а просто при наличие ошибок начать поиск их причин. Либо применять более надёжные методы коррекции ошибок на более высоких уровнях.
Зачем вообще нужны варианты длительности стоп-бита, отличные от 1?
Наличие 1,5 и 2 бит скорее исторически обусловлено. Большее количество стоп-бит даёт принимающему устройству больше времени на раскладывание бит принятого символа по своим внутренним регистрам. Сейчас, конечно, учитывая, что оверсемплинг (а значит и само принимающее устройство) работает на порядок быстрее базового битрейта, современные устройства должны всё успевать за 1 стоп-бит.
В первом случае, если соседний фронт съедет на 37,5% от длительности бита, то будет ошибка, если меньше, то не будет. Во втором случае фронт для возникновения ошибки должен съехать на 43,75%.Но и то, и другое — совершенно ненормальная ситуация, далеко выходящая даже за 25%. Это, конечно, некоторое преимущество, но на мой взгляд, не существенное.
Есть мнение, что не нужно ожидать, пока «мажорирование <...> с большей вероятностью выдаст правильный результат», а просто при наличие ошибок начать поиск их причин.Если ошибки обнаруживаются на этапе испытаний — конечно, нужно разобраться в причинах их возникновения. Это одна из причин, почему не стоит использовать устаревшие микроконтроллеры — в ATmega программа просто не может обнаружить шум, который был отфильтрован мажоритарной схемой UART — там UART не имеет флага noise. Но если ошибки не возникают на испытаниях — это еще не значит, что они не будут возникать в эксплуатации, потому что всегда возможны внешние воздействия, превышающие то, на что устройство было рассчитано, и если мажоритарная схема позволяет с ними справиться — значит её нужно использовать.
Но если ошибки не возникают на испытаниях — это еще не значит, что они не будут возникать в эксплуатации, потому что всегда возможны внешние воздействия, превышающие то, на что устройство было рассчитано
Есть мнение, что если внешние воздействия превышают то, на что устройство было рассчитано, то его не следует эксплуатировать в подобных внешних условиях :)
С другой стороны, требования бизнеса по срокам и стоимости могут быть различны. Где-то есть время и деньги, скажем, на изготовление специального кронштейна, а где-то синяя изолента будет признана лучшим решением по соотношению цена/качество.
На мой взгляд, с мажорированием - аналогичная ситуация.
К слову, не плохо было бы рассказать про автоматическое определение скорости. Небольшой appnote на эту тему от STmicro.
UPD: Заметка в Википедии на тему Automatic Baudrate Detection.
Статья понравилась! Буду рекомендовать для обучения всем, кто не знаком с uart и 232'м
Типичный битрейт — 9600 бит/с
лол. в усб-уарт нынче битрейт можно мегабитный задать, но если почитать форумы то со скоростью выше 115.4 возникают проблеммы. получается зоопарк переходников, систем и драйверов которые ведут себя по разному. а еще производители любят создавать "фирменные" переходники с нестандартными скоростями.
кстати, в промышленных компах ком порт бывает стандартов RS-485/RS-422
лол. в усб-уарт нынче битрейт можно мегабитный задать, но если почитать форумы то со скоростью выше 115.4 возникают проблеммы
Это правда, видеопоток через UART пропустить хоть и, теоретически, возможно, но проблематично.
Где UART хорош, так это в управлении, в передаче команд. Выставить ток, напряжение и сказать "включись!" тому же Keithley - здесь и 9600 бит/с хватает (с потоком данных от Keithley чуть сложнее, но терпимо). И отлаживать такой поток куда проще, чем многие другие протоколы. В (самом) крайнем случае даже палец, водящий по осциллограмме сгодится :) С USB, к примеру, так не поводишь :)
а классический стандарт на скорости свыше 115200 бод не распространяется да и даже далеко не все современные трансляторы уровней TTL-RS232 поддерживают скорости бод свыше 250к.
и в ОС обычно но не всегда, значение энума например BOD_9600 равно 9600 как инт32. Но иногда это например 7 (как седьмая по счёту константа) и размер параметра не int32 а int8 и другие скорости попросту не выбрать или выбрать надо спец параметрами через ioctl
И даже на уровне USB endpoint мостов уарт-усб реализованы аппаратно и поэтому они максимально мелкие, максимум под 115200. Это было например в самых старых первых аппаратных чипах и быстрее передавать попросту не могут без багов.
Тоесть, порой это и логически и физически невозможно.
Или возможно но с кучей ограничений (например нельзя непрерывно передавать на скоростях свыше 115.2кбод - обязательно делать паузы раз в миллисекунду чтоб усб успел отправить).
Упомянутый FT232R — может до мегабита, ЕМНИП. 460,8 и 500 кБод я точно передавал (с TTL уровнями).
Кстати, хотел как-то сделать полностью лживый виртуальный USB-RS232, в котором вообще нет RS232, а есть оптопара на другой такой же лживый порт :) и скорость обещать какую-нибудь запредельную. И с другой стороны — симметрично. Микроконтроллеров — два, то есть полная опторазвязка.
То есть такой NULL-USB кабель, который дровами видится как нуль-модемный кабель на двух виртуальных портах, обеспечивая при этом скорость «на все деньги» (реально-то там нигде нет униполярного сигнала в вольтажах RS232).
А потом купил две USB-сетевухи и обжал хвостик 20 см, после чего стало лень :)
В этом случае иногда происходит некоторая путаница с разъёмами. Если разъём DB-9 на материнской плате — всегда «папа» (штыри), то разъём на оборудовании почти всегда «папа». Исключение — прецизионные источники питания компании Keithley (которую купил Tektronix). У них разъём «мама» (гнёзда). Разъём же на преобразователях USB-RS232 почти всегда, как и на материнских платах — «папа». Соответственно, он может быть подключен к Keithley непосредственно.
Вроде бы традиционно считается, что разъём с гнёздами (как на модемах, некоторых бесперебойниках, упомянутых тут ЛБП) требует модемного кабеля (для прямого подключения к ПК), а разъём со штырьками (кассовые аппараты, телефоны, терминалы, всякое оборудование с таким интерфейсом, другие компьютеры) — нуль-модемного (перекрёстного, RX/TX, RTS/CTS). Но, сдаётся мне, и это где-то, да не соблюдается.
Ну и не стоит забывать, что производитель может по приколу (а на деле из желания заставить вас купить именно его кабель) может поменять местами контакты в разъёме, как, например, это сделали в ИБП компании APC. Если такой подрубить обычным модемным кабелем, он непрерывно пищит и не запускается.
возможно будет интересно про разъемы DB-9 и DB-25, здесь даже не история, а типа археология, для первых широко доступных модемов это был интерфейс DCE-DTE, между самим модемом и тем что им управляло, например компьютер или терминал, задействовано было 9 контактов из 25, Tx,Rx, остальные связаны с установлением телефонного соединения, например ringing, и управлением передачей двнных, ringing можно было использовать например как прерывание, DB-9 это в общем упрощенный вариант DB-25, те же сигналы но размещены иначе (буква D = форма разъема), как и RS-232 DB-25 появился в начале 60х в виде рекомендаций фактически на основе того что уже использовалось для модемов Bell 101 (1958, 110 bps) и Bell 103 (1962, 300 bps ) это были первые два модема доступные на рынке, в IBM PC разъемы вероятно попали потому, что хотели типа max переиспользовать, то что уже было на рынке для mini, так продлили жизнь этим разъемам еще на 20-30 лет, интересно что рабочие модемы на самом деле первые появились еще в начале 50х, но не в свободной продаже, а использовались для sage, выпускала их другая фирма не ATT (= Bell), скорость передачи данных тоже была выше, ATT участвовала в проекте sage обеспечивая каналы связи, поскольку телефонная сеть тогда ей полностью принадлежала, так получила опыт и доступ к технологии разработанной MIT, ниже на картинке Bell 103, 1962
ps
в то время Western Electric это производственное отделение AT&T, а Bell ее научное отделение
pps
9 линий интерфейса DTE-DCE (DB9/DB25) стали типа избыточными с началом использования в начале 80х Hayes AT команд стандартных сейчас для управления модемами, это конечно требует контроллера в составе модема, переключения в командный режим при помощи escape sequence и тд., но позволяет легко управлять модемом при помощи скриптов
Добавлю, что Hayes модем (это первый модем для персональных компьютеров) и набор команд для модема создал Dale Heatherington (он же основатель фирмы Hayes ). В 85 г Дэйл оставил фирму (там была интересная, но не очень приятная история "развода" с его партнером Hayes... , и получил 20 миллионов долларов.) В результате в 98 г. фирма благополучно стала банкротом, сам Hayes поучаствовал в приближении конца).
К сожалению недавно жизнь Дэйла оборвалась.
Дэйл вел свой личный сайт , где много интересной технической информации и истории.
Я с ним познакомился в далеких 2000-ых в клубе роботов AHRC в Атланте (один из первых в Америке). Дэйл был фанат роботов в лучшем смысле.
В память о Дэйле мой друг Keith сделал нарезку видео с битвами роботов
Андрей спасибо, за хороший комментарий, когда pc появились на этих модемах сделал remote control типа Meridian carbon copy, но для управление конкретным продуктом, интегрированный поэтому работал быстрее чем carbon copy, пришлось с hw достаточно поиграть, давно однако было :)
Интернет здорового человека :)
Тщательно пишешь статью.
Публикуешь её.
В комментариях дают развёрнутую историческую справку (с иллюстрациями).
В комментариях к исторической справке появляется практически очевидец событий с весьма редкими ссылками.
То, как виделась глобальная сеть в фантастике конца 70-х ))))
На первом графике указано состояние "Пауза". Смысл её для асимметричной передачи мне прекрасно понятен, но всегда оставалось тайной - какова её длительность ?
Мой опыт показывает, что при надлежащих условиях скорость передачи данных достигает максимума, т.е. при стандартных настройках порта 8-N-1 (10 бит на символ) скорость передачи данных достигает Baudrate/10. Вроде всё просто, но если нет "паузы" - невозможно отличить последовательность "start bit -> stop bit" от бит данных. Тем не менее - работает !
Вполне возможно, что количество стоп бит 1.5 и 2 были придуманы именно для этого, причем 1.5 предпочтительнее т.к. его можно однозначно идентифицировать по нестандартной длительности.
При наличии линий CTS/RTS проблемы нет, но меня интересует именно случай трехпроводного соединения RX/TX/GND.
Смысл её для асимметричной передачи мне прекрасно понятен, но всегда оставалось тайной - какова её длительность
Минимальная длительность паузы - это оговоренное количество стоп-битов. Если оговорен 1 стоп-бит, то минимальная пауза - это он и есть.
Вроде всё просто, но если нет "паузы" - невозможно отличить последовательность "start bit -> stop bit" от бит данных.
Возможно, вы имели ввиду "stop_bit -> start_bit", потому как переход "start_bit -> stop_bit" разделяют как раз биты данных.
Если так, то вообще говоря, определить окончание символа можно просто посчитав биты данных - стоп-бит для этого не нужен. Он нужен для того, чтобы у старт-бита был нисходящий фронт. По которому можно было бы обнулить накопленное рассогласование тактирующих систем передатчика и приёмника. В 50% случаев этот фронт и так бы был у старт бита (даже в случае гипотетического отсутствия стоп-бита). Но чтобы нисходящий фронт был с гарантией 100% и добавляют стоп-бит.
Если же представить плотный поток данных, к которому внезапно подключается USB-UART, то да, определить - где данные, а где служебные биты будет невозможно. Я бы сказал, пауза, достаточная для определения начала непрерывного потока данных формата 8N1 - 10 логических единиц подряд.
Неизвестный UART: теория