Комментарии 29
Для тестов я решил взять три наиболее популярных сейчас микросхемы USB-UART: CP2102, FT232 и CH340. Первые две микросхемы можно купить на алиэкспрессе на платах с нужными нам выводами. Только на модулях с FT232 очень часто стоит фейковая микросхема, которая постоянно зависает, поэтому лучше их вообще там не покупать.
Модули с фейковыми CH340 тоже бывают. Под маркировкой CH340G абсолюно левая по прозвонке выводов микра и бутафрский кварц, никуда не идущий. Работают подделки нормально (система видит как CH340), вот только кроме RX, TX больше ничего нет.
А вот для микросхемы CH340 распространены только модули с основными выводами RX и TX, без дополнительных
вот здесь есть DTR
на этом есть RTS,CTS
на этом есть RTS,CTS,DTR
Вроде в мс FTDI есть режим Bit-banging, не проще ли через это действать?
Не уверен, что проще, вроде бы это делается через SDK от FTDI, а не через функции COM-порта. То есть, надо будет что-то ставить и изучать другие функции. Да и решение будет не универсальным. Хотя, конечно, так было бы больше возможностей. Но так то и дешёвый микроконтроллер поставить на UART не так уж сложно:)
Для ftdi вариантов не мало, например библиотека и на python.
А еще можно зайти на сайт производителя и найти библиотеки даже под visualBasic. там есть уже непросто ногодрыг, а сразу еще реализованы интерфейсы i2C/SPI/jtag. Что и используют производители огромного числа программаторов/отладчиков на базе микросхемы FT2232H для огромного числа микросхем.
Аналогичные штуки есть и в серии usb интерфейсов CP и CH.
конечно придется чему то подучиться но и работает это все заметно быстрее.
Оригинальную FTDI, где SN не A50285BI, ещё нужно постараться найти.
Для ногодрыга бы пожалуй подошла CH341, которая известна всем по одноимённому программатору.
Как у автора FT232 у меня вполне работает.
А вы знали про возможности этих дополнительных выводов USB-UART?
Да, использую их вместо отсутствующих в подавляющем большинстве компьютеров GPIO. Мой основной кейс - управление любительской радиостанцией, переключение с приема на передачу, чтение статуса шумоподавителя и тому подобные нехитрые действия, которые хорошо поддерживаются соответствующим софтом и работают по сути везде, где есть USB порты. Да, более продвинутые радиостанции принимают расширенные команды по UART (COM) и отвечают на них - позволяют устанавливать практически все параметры и отчитываться об их статусе, начиная с очевидной установки частоты и вида модуляции, но и с ними переключение прием/передача лучше осуществлять примитивным, быстрым и надежным сигналом на RTS или DTR, а не ждать, пока управляющий софт сформирует и отправит команду, а радиостанция ее распарсит и выполнит - просто сменить уровень быстрее и помехозащищеннее. В результате все это делается на одном USB-UART, проще не придумаешь.
Кому такого импровизированного GPIO мало, подумайте об USB-LPT адаптере. :)
Ничего не понятно, но выглядит круто:) Пока читал ваш комментарий, пришла идея: можно через DTR и RTS управлять электронными ключами (типа DG408 или 74HC4066), чтобы "нажимать" отдельные кнопки на плате от клавиатуры или других устройств. То есть, получается программное нажатие, но распознаваться будет как реальное от пользователя.
CH340 бывают очень разные. У CH340N, например, всего 8 выводов, 6 из которых это Vcc, GND, Tx, Rx, D+, D-.
Да, эта миниатюрная версия мне очень нравится, она прям создана для каких-то портативных устройств.
В плане миниатюрности CH340N всё же не самый маленький мост :)
Он занимает 5х6мм.
А, например, CP2102N-A02-GQFN20 занимает 3х3мм.
Но миниатюризация чипа с определённого момента начинает быть не вполне осмысленной - разъём-то не уменьшить ниже определённого уровня.
Я тут, кстати, накидал небольшой обзор всяких разных мостов, чтобы оценивать, скажем так, тенденции и масштабы.
Мне больше нравится cp2104, шустрая, стабильная, есть отдельные GPIO с управлением, правда, через их API, можно зашить конфиг с нужным VID/PID и настройками GPIO (правда, только два раза)
Благодарю!
Очень хорошо структурированная статья, более того, ценная не только кодом и использованием сейчас, после COM-мышей, данных выводов, но и различными примерами аппаратного окружения, в одной статье.
О всех этих микросхемах вроде помнишь, а когда доходит до тела-дела, вечно начинаешь тупить и искать конкретные применения.
Ну а код можно написать любой, благо что при наличии офисных пакетов почти на всех компьютерах, питон и Васик (Оба в MS и в Либре Офисах всегда в наличии) всегда при нас, даже в урезаной офисной машинке ;).
Да, способ этот известен с древних времен. В некоторых компьютерах 80-ых, в целях экономии, чтобы не ставить лишние корпуса i8255, использовали редко используемые линии полного RS-232 (типа Ring Indicator) как линии последовательного ввода-вывода.
Мне вспомнилась статья, где неиспользованные линии RS-232 использовались для питания преобразователя RS-232 <-> UART.
По поводу
Полученные таблицы со временем работы функций оказались немного странными.
в C# использовать DateTime.Now для оценки времени не самая удачная идея. Можно посмотреть, например, здесь - https://habr.com/ru/companies/tbank/articles/454058/ или тут - https://ru.stackoverflow.com/questions/758708/Как-точно-измерить-время-выполнения-операции-С
Судя по описанию функции DateTime.Now.Ticks, она выдаёт таймкод с шагом 100 нс. Это очень даже точно для моих задач:) Я её немного протестировал вместе с осциллографом и вроде бы она вполне точно показывает отсчёты как для измерения времени, так и для организации задержки в цикле.
Если бы функции COM-порта работали значительно быстрее, тогда, действительно, лучше было бы использовать специальные методы. Но тут я уже знал, что функции работают медленно (так как видел на осциллографе задержки в миллисекунды), поэтому такого таймера вполне достаточно.
RTS/CTS не "когда-то давно", а в любой момент могут быть использованы для приостановки потока по uart'у, если вдруг имбеднутый девайс не вывозит.
DTR можно заводить (через джампер есс-но или нормально невпаянный резистор) на сброс девайса, тогда распальцовка в терминалке позволяет удобно девайс сбрасывать при отладке.
Вы имеете ввиду, что микросхемы USB-UART автоматически перестанут передавать данные, если на CTS будет 0? Что-то мне кажется, это не работает, иначе нужно было бы обязательно подтягивать эти входы к питанию. Если это самому можно отслеживать в своей передающей программе, тогда это неплохой вариант использования. Правда можно просто пореже передавать данные, чтобы не переполнять буфер устройства.
Насчёт ресета девайса: возможно, можно придумать какую-то хитрую логическую схему, чтобы устройство не сбрасывалось случайно при подключении и отключении USB. Например, можно выводить через DTR и RTS специальные комбинации для ресета устройства и активации бутлоадера при необходимости обновить прошивку. Я это продумывал для программатора STM32, но это достаточно сильное усложнение и проще заставить пользователя переключателем выбирать режим "работа" или "прошивка". Хотя для каких-то проектов это может быть актуально.
Публикации
Использование выводов DTR, RTS и CTS от UART для своих делишек