-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Прошивка TCP2UART переходника с настройкой по Web
- Автор темы pvvx
- Дата начала
pvvx, перечитал всю тему но не нашел ответа на вопрос:
Может ли модуль ESP8266 с вашей прошивкой на борту полноценно и прозрачно заменить usb-uart адаптеры для заливки скетчей в Arduino-платы?
Принципиальный момент для этого - дёрганье линии DTR перед началом заливки для сброса ардуинки.
Реализована ли вообще работа линии DTR сейчас? Если нет, то можно ли это реализовать?
Спасибо.
Может ли модуль ESP8266 с вашей прошивкой на борту полноценно и прозрачно заменить usb-uart адаптеры для заливки скетчей в Arduino-платы?
Принципиальный момент для этого - дёрганье линии DTR перед началом заливки для сброса ардуинки.
Реализована ли вообще работа линии DTR сейчас? Если нет, то можно ли это реализовать?
Спасибо.
pvvx
Активный участник сообщества
Для этого проще сделать драйвер TCP-Modbus. С ним меньше проблем, т.к. буфера всего до 256 байт. TCP-Modbus поддерживается многим ПО и не является аналогом переходника TCP-UART - там другой протокол и значительно проще обслуживается в ESP8266, т.к. он синхронно-блочный - в нем прием и передача коротких пакетов TCP со своими заголовками, а не непрерывных потоков и не нужны большие буфера.
Счас это организуется внешним протоколом.
DTR линия не обслуживается. Но её можно переводить в любое состояние как вывод I/O в Web запросе.
Т.е. перед открытием порта TCP-UART по HTTP надо передать установку выбаранного вывода в желаемое состояние. К примеру так http://sesp8266/web.cgi?gpioX_dir=1&gpioX_out=0&gpioX_out=1 , где X - номер GPIO, а затем открыть TCP-UART порт и принимать/передавать данные.
Т.к. линии RTS/CTS не задействованы у Ар"дурино", то чтобы не было потерь данных и обеспечить дуплекс, необходимо передавать данные, к примеру, мелкими пачками с паузами, с учетом не превышения общего трафика скорости UART.
У меня никогда не было ни одной Ар"дурино" платы (и наверно не будет). По тому сказать конкретно, что необходимо для поддержки их убогого интерфейса не могу.
Загрузчики ПО делаются обычно по другому - передается файл полностью, потом он проверяется и уже затем заливается c учетом всяких возможных протоколов. Иначе можно потерять работоспособность "прошиваемого" устройства. Flash у ESP8266 есть - в неё и принимается файл по стандартному протоколу HTTP. Т.е. необходима другая программа на ESP8266. Думаю, что это в скором времени сделают в самой среде Ар"дурино" - это не так сложно и обращайтесь к проектам Sming и Arduino + ESP8266.
Последнее редактирование:
Речь шла не о MODBUS или каком либо другом протоколе, а о возможности управлять передачей TxOn/TxOFF на трансивере RS485. Обычно для этого используется нога RTS.
Последнее редактирование:
pvvx
Активный участник сообщества
Тогда что-то работать должно
Но кто будет делать арбитраж? Временем передачи пакетов? В него будет входить тайм-аут скорости передачи по сети, а это может быть очень много - до 5 секунд в одну сторону, если связь идет через GSM и подобное... Сама аппаратная реализация DSR DTR в UART ESP8266 практически ими не управляет. По тому была исключена из реализации.
Последнее редактирование:
shaman1010
Member
Так на скрине они ж есть
только белые
pvvx
Активный участник сообщества
Кто-то сменил цвета в палитре для IE по умолчаниюТак на скрине они ж есть
Ещё где-то откопал старую версию IE...не такая она уж и старая
Че блин за палитра в IE, первый раз слышу, ну да ладно, не очень то и хотелось
pvvx
Активный участник сообщества
.не такая она уж и старая
Не нашел инструкций как пользоваться сабжем на писюке. Задача: получить виртуальный компорт проброшенный по wifi.
Пришлось экспериментировать.
Собрал прошивку из исходников в теме Разработка ‘библиотеки’ малого webсервера на esp8266 (пришлось править makefile чтобы под линуксом компилялось).
Попробовал работу с TCP2UART Tester - работает.
Теперь надо виртуальный ком порт на винду.
Пробовал софт от HW Group - он не заработал.
Поставил com0com и hub4com - виртуальный порт создался, связь с TCP2UART есть, данные передаются в обе стороны.
Но есть нюанс: про открытии / закрытии виртуального порта на писюке в UART esp сыпется мусор.
Может я что-то делаю не так ?
Пришлось экспериментировать.
Собрал прошивку из исходников в теме Разработка ‘библиотеки’ малого webсервера на esp8266 (пришлось править makefile чтобы под линуксом компилялось).
Попробовал работу с TCP2UART Tester - работает.
Теперь надо виртуальный ком порт на винду.
Пробовал софт от HW Group - он не заработал.
Поставил com0com и hub4com - виртуальный порт создался, связь с TCP2UART есть, данные передаются в обе стороны.
Но есть нюанс: про открытии / закрытии виртуального порта на писюке в UART esp сыпется мусор.
Может я что-то делаю не так ?
pvvx
Активный участник сообщества
А данная версия не есть устройство для какого-то драйвера эмуляции COM порта. Это просто сокет для любого простого приложения и не принимает специфических команд настроек порта от драйверов (то что в виде мусора). Драйверов много и у каждого свой протокол. Стандарта у них нет.
Зачем что-то собирать, если есть готовая прошивка в виде bin файлов, а тут и fullflash.bin?
Вот терминал к примеру в Eclipse:
Или на Яве или вообще на телефоне с App Inventor...
На телефоне тоже будете ставить COM-port эмулятор?
Последнее редактирование:
rfc2217
Имеющийся софт который будет общаться с Tcp2uart ничего кроме com порта не знает. Поэтому либо виртуальный ком либо никак. Телефон не интересует потому что нужного софта под телефоны еще не написали и в обозримое время не напишут.Зачем что-то собирать, если есть готовая прошивка в виде bin файлов, а тут и fullflash.bin?
Вот терминал к примеру в Eclipse:
Или на Яве или вообще на телефоне с App Inventor...
На телефоне тоже будете ставить COM-port эмулятор?
Собирать из исходников для изучения реализации tcp2uart.
pvvx
Активный участник сообщества
@sharikov
rfc2217 - Этот документ определяет экспериментальный протокол для Интернет сообщества.
Там сказано, что клиент может отправить команды управления линиями и настройки передачи в любой момент и несколько раз в течение сессии Telnet. Но нет определения самого протокола разделяющего данные от команд. Кривой этот док и нигде не пользуется.
rfc2217 - Этот документ определяет экспериментальный протокол для Интернет сообщества.
Там сказано, что клиент может отправить команды управления линиями и настройки передачи в любой момент и несколько раз в течение сессии Telnet. Но нет определения самого протокола разделяющего данные от команд.
Кривой этот док и нигде не пользуется.У меня он работает с моими устройствами, некоторым которым уже за десяток лет. Используется доступ просто через TCP-сокет из софта на компе и ничего не переделывается.
Vladimir555
Member
Уважаемый pvvx!
Огромное спасибо за проделанную работу.
Впечатляет.
Возник один вопрос.
Нужен протокол UDP для общения с COM.
Это возможно в вашем проекте?
Огромное спасибо за проделанную работу.
Впечатляет.
Возник один вопрос.
Нужен протокол UDP для общения с COM.
Это возможно в вашем проекте?
pvvx
Активный участник сообщества
Нет - UDP дает потерю пакетов, а в WiFi это часто...
Vladimir555
Member
Pvvx, спасибо за ответ.
Абсолютно верно.
TCP- почти гарантированная доставка пакетов, но возможны большие задержки.
UDP– возможная потеря пакетов, но малые задержки.
Есть ряд задач где UDP работает на много лучше, не смотря на потери.
Может есть “засада” с малым ОЗУ или тонкостями этого стека
Нужно только заменить соединение на UDP для UART,
не изменяя веб дизайн и cgi. Назвать проект UDP2UART.
Если все таки есть такая возможность, думаю многие оценят.
Спасибо
Абсолютно верно.
TCP- почти гарантированная доставка пакетов, но возможны большие задержки.
UDP– возможная потеря пакетов, но малые задержки.
Есть ряд задач где UDP работает на много лучше, не смотря на потери.
Может есть “засада” с малым ОЗУ или тонкостями этого стека
Нужно только заменить соединение на UDP для UART,
не изменяя веб дизайн и cgi. Назвать проект UDP2UART.
Если все таки есть такая возможность, думаю многие оценят.
Спасибо
Допустим клиент UDP перестал принимать пакеты (дите засунула устройство в жестяную коробку из-под конфет
реальный случай), а соединение остается открытым и пакеты будут просто уходить в никуда. Следовательно надо будет городить протокол с подтверждением. На мой взгляд лучше уж решать на уровне TCP такую задачу.Vladimir555
Member
Andy Korg,
Согласен.
Потеря связи возможна особенно по Wi-Fi, нужны подтверждения и timeout.
Но при передачи звукового потока или реалтайм управления возникшие задержки в TCP очень большие (идут запросы битых пакетов туда - сюда это на много больше одного битого UDP пакета ).
Не случайно Skype и Sip работают с UDP.
TCP хорош для веб страниц, не чего не пропадает рано или поздно нарисуется, для почты, sms и тд.
Я так понимаю в проекте TCP2UART пока добавить UDP поток и "клиент соединения" нет возможности.
Спасибо.
Согласен.
Потеря связи возможна особенно по Wi-Fi, нужны подтверждения и timeout.
Но при передачи звукового потока или реалтайм управления возникшие задержки в TCP очень большие (идут запросы битых пакетов туда - сюда это на много больше одного битого UDP пакета ).
Не случайно Skype и Sip работают с UDP.
TCP хорош для веб страниц, не чего не пропадает рано или поздно нарисуется, для почты, sms и тд.
Я так понимаю в проекте TCP2UART пока добавить UDP поток и "клиент соединения" нет возможности.
Спасибо.