• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Прошивка TCP2UART переходника с настройкой по Web

Pilowar

New member
UART молчит. Есть ещё нюанс один, при переводе в STATION_MODE клиент пропадает из списка доступных сетей.
Синий диод помигивает.
Ещё заметил при подключении к серверу через WEB IP адрес присвоенный моему компьютеру заканчивается на 3, а 2 должен быть клиентом, но связи по UART нет...
Скриншоты с настройкой приложил, были сняты уже после настройки и перезагрузки.
 

Вложения

shaman1010

Member
адрес присвоенный моему компьютеру
Перечитай, что я тебе выше написал.
подсказака - STA - это режим клиента, AP - точки доступа.
Настраиваешь одну как AP, ее-же сервером, вторую как AP+STA - заходишь на вторую точку доступа (SSID AP1 != SSID AP2) и настраиваешь ее клиентом к AP1. Проверяешь связь, когда все проверишь перенастрой клиента просто в STA, без поднятия второй точки доступа.
 

Bobr

New member
Esp-Link с библиотекой El-Client. Там встроенные сокеты TCP. Стабильность - приемлемая. Вы понимаете, что это решение требует наличие Ардуины? Желательно 328p.
Esp-Link не поддерживает скорость 2400, т.е. в настройках она есть, но если выбрать то 8266 зависает и нужно заново перепрошивать на другую прошивку не Esp-Link...
 
Для тех кому не понятно как установить прошивку в конце видео это есть и делается в течении 2х минут(УРОВЕНЬ ШКОЛЬНИКА и ниже). Также есть тест на примере передачи изображения.
 

Павел777

New member
Добрый день! Прошу помощи у тех немногочисленных людей, кто сюда еще зайдет)
Использую ESP07 с данной прошивкой в режиме клиент+сервер. Стабильно работает около месяца, потом клиент отваливается от сети, а при попытке зайти на веб-морду - как то рандомно меняется логин, поле пароля пустое. Почему могут слетать настройки?
Сбрасываю модуль ногой RX на землю, настраиваю заново и работает еще около месяца. Так уже раза 4 или 5 было.
 

Вложения

aloika

Active member
Добрый день! Прошу помощи у тех немногочисленных людей, кто сюда еще зайдет)
Использую ESP07 с данной прошивкой в режиме клиент+сервер. Стабильно работает около месяца, потом клиент отваливается от сети, а при попытке зайти на веб-морду - как то рандомно меняется логин, поле пароля пустое. Почему могут слетать настройки?
Сбрасываю модуль ногой RX на землю, настраиваю заново и работает еще около месяца. Так уже раза 4 или 5 было.
Это все потому, что ESP8266 использовать не надо, она сама по себе нестабильная. Используйте RTL8710AF, например. Или можно попробовать серию B - RTL8710Bx. Эти модули/чипы гораздо стабильнее.
 

ivanpost67

New member
Добрый день! Прошу помощи у тех немногочисленных людей, кто сюда еще зайдет)
Использую ESP07 с данной прошивкой в режиме клиент+сервер. Стабильно работает около месяца, потом клиент отваливается от сети, а при попытке зайти на веб-морду - как то рандомно меняется логин, поле пароля пустое. Почему могут слетать настройки?
Сбрасываю модуль ногой RX на землю, настраиваю заново и работает еще около месяца. Так уже раза 4 или 5 было.
Используйте прошивку Esp-link. В плане uart она стабильна. есть фичи, типа OTA. https://github.com/jeelabs/esp-link
 

achilles85

New member
Прошил модуль 12E крайней прошивкой. В настройках tcp2uart выставляю скорость 38400, после применения настроек скорость становится 38406. Оборудование, к которому подключен переходник, хочет 38400. Как выйти из положения?
 

koziymf

New member
Вопросов нет, просто большая благодарность за прошивку! Искал uart-wifi-wifi-uart решение для 2х модулей, и только эта статья / решение помогли. Работает отлично.
 

Evgeniy932

New member
Недостаток вообще всех прошивок мостов TCP <> UART в том, что они не поддерживают обмен на уровне сообщений, а не байт.
Например, тот же протокол WebSockets.
Бывают устройства на RS232/RS485, в протоколах которых не используется кодовое разделение пакетов в потоке, вместо этого - таймауты.
С такими устройствами невозможно работать особенно, если на ноутбуке включен режим энергосбережения.
 

pvvx

Активный участник сообщества
Недостаток вообще всех прошивок мостов TCP <> UART в том, что они не поддерживают обмен на уровне сообщений, а не байт.
Например, тот же протокол WebSockets.
Бывают устройства на RS232/RS485, в протоколах которых не используется кодовое разделение пакетов в потоке, вместо этого - таймауты.
С такими устройствами невозможно работать особенно, если на ноутбуке включен режим энергосбережения.
Т.е. ваш ноутбук не может работать с арбитражем использующим временные составляющие?
Тогда это его беда, а не "всех прошивок мостов TCP <> UART".
 

pvvx

Активный участник сообщества
Разделение пакетов по таймаутам на RS232/RS485 производит конечный драйвер и при чем тут Ноут, у которого нет реал-тайм ОС?
Для этого обычно используют Modbus TCP - это в соседней теме...
 

Evgeniy932

New member
Т.е. ваш ноутбук не может работать с арбитражем использующим временные составляющие?
Тогда это его беда, а не "всех прошивок мостов TCP <> UART".
Нет, ноутбук здесь вообще непричем.
Я говорю об устройстве, которое подключается со стороны RS232/485 интерфейса.
Это может быть произвольное устройство.
Вот мне повезло найти такое, которое разделяет пакеты по таймауту, а не по символам начала и конца пакета.
Получилось так, что из готовых прошивок ни одна не подошла под такую задачу.
Под 8266 попробую потом с ESP32 перенести.
 

pvvx

Активный участник сообщества
А данная прошивка тоже разделяет пакеты по таймауту... Но это не её специализация, т.к. поток складывается в пакеты TCP и если паузы малые, то попадет в один пакет передачи...
И это вообще глупо - как можно передавать поток, да с разделением по паузам, если замирания в WiFi больше пауз? У ESP, хоть 32, нет таких буферов.
Вам наверно нужно что-то типа:
 
Последнее редактирование:

Evgeniy932

New member
А данная прошивка тоже разделяет пакеты по таймауту... Но это не её специализация, т.к. поток складывается в пакеты TCP и если паузы малые, то попадет в один пакет передачи...
И это вообще глупо - как можно передавать поток, да с разделением по паузам, если замирания в WiFi больше пауз? У ESP, хоть 32, нет таких буферов.
Так потому я так и не делаю, конечно это неправильно.

1) Основная масса прошивок TCP <> UART имеют ограниченное применение, потому что не всегда на уровне RS232/RS485 используются протоколы с кодовым разделением пакетов в потоке (байтстаффинг, текстовые протоколы и т.п.), не всегда используется MODBUS.
2) Из-за причины из пункта 1. происходят проблемы с непредсказуемыми сетевыми задержками, обычно это режим энергосбережения WiFi, но бывает, что на некоторых смартфонах доставка по TCP происходит с задержкой, зачастую данные передаются за несколько вызовов write(sock, ...), а считываются одним куском через read(sock, ...)
3) Это приводит к проблемами на стороне протокола по RS232/RS485
4) Решение с TCP можно использовать в режиме прозрачного моста только, если протокол на уровне RS232/RS485 имеет кодовое выделение пакетов из потока (например, байт-стаффинг)

Решение с WebSockets работает стабильно при любом раскладе, т.к. обеспечивает доставку на уровне сообщений, а не отдельных байт.
Решение на WebSockets - универсально для любых задач, связанных с прозрачной коммуникацией.

Мне был нужен стабильный мост с надежным асинхронным протоколом, с одной стороны и UART 921600 бод/с & RS485 с отключением DRIVER ENABLE на RS485 за 1.3...1.6 мкс.
Это является нормальным требованием, касаемо RS485 и протокола общения по WiFi.
У меня это получилось сделать.

Вам наверно нужно что-то типа:
Вот вы не понимаете о чем речь идет и отпускаете глупые шутки.
Я вообще ожидал, что с вами можно обсудить технические нюансы, с которыми ардуинщики не сталкиваются.

Мне вот повезло столкнуться с ни чем не оправданной заниженной пропускной способностью на одном из смартфонов, пробовал разные режимы WiFI b/g/n, их комбинации - не нашел связи с этим, режимы энергосбережения отключил - бесполезно. На других смартфонах до 60 мбит/с. Одинаково заниженная пропускная способность на ESP8266 и на ESP32 только с конкретной моделью смартфона. Замеры делал на ESP32.
Было бы интересно с этим поделиться с сообществом и найти причину.
В моей задаче - заниженная пропускная способность особой роли не сыграла, но интересно решить.
Может вы с этим сталкивались, что-то подскажете?
 

Evgeniy932

New member
Тогда это его беда, а не "всех прошивок мостов TCP <> UART".
Почти все готовые прошивки не умеют:
1) Правильно управлять сигналом RS485 DEN, обычно затянутое отключение драйвера приводит к потери байт на стандартном ряде битрейтов. (устройство НЕ должно отвечать позже, чем через длительность двух битов, это мост должен правильно управлять сигналом отключения драйвера)
2) Не поддерживают половину стандартного ряда битрейтов UART в настройках или поддерживают, но тогда причина 1)
3) Нет надежной доставки данных по WiFi, бОльшая часть прошивок не справляется с передачей данных от 32 кб через WiFi, даже если приемный буфер не переполняется.
4) Ограниченное применение из-за отсутствия протокола транспортного уровня поверх TCP (я пробовал делать свой протокол для транспортного уровня, но ушел на WebSockets, впрочем оба решения оказались на порядок лучше голого TCP)

Вообщем-то, можно и свой вариант развить до версии моста для ESP32, выложить в OpenSource, но пока рановато.
 

pvvx

Активный участник сообщества
Почти все готовые прошивки не умеют:
1) Правильно управлять сигналом RS485 DEN, обычно затянутое отключение драйвера приводит к потери байт на стандартном ряде битрейтов. (устройство НЕ должно отвечать позже, чем через длительность двух битов, это мост должен правильно управлять сигналом отключения драйвера)
Для Modbus RTU удержание 'DEN' после последнего символа должно быть равно протокольной паузе из стандарта. Если отключение EN будет ранее - появление помех на линии будет боле вероятно, т.к. линия будет не нагружена.

2) Не поддерживают половину стандартного ряда битрейтов UART в настройках или поддерживают, но тогда причина 1)
Стандартный ряд от 300 до 115200 с известной кратностью. Но менее 9600, включительно, уже изжили cебя полностью. Никто уже не тянет километровую проводную линию, для которой подходит этот 9600...
В итого остаются 19200, 38400, 57600, 115200. Это всё.
Или о каких стандартах вы говорите?
3) Нет надежной доставки данных по WiFi, бОльшая часть прошивок не справляется с передачей данных от 32 кб через WiFi, даже если приемный буфер не переполняется.
И не справится. Для нормальной работы только TCP сокета вам потребуется от пол мегабайта статических буферов и ещё сколько-то для буферизации потока. Учитывая поддержку других сервисов - это цифра неизбежно подходит к 1 Мегабайту. Берите RTL8195 (в ней более 2 MIB RAM) или другие, с аналогичными объемами, задавайте все статические буфера для Lwip и всё будет Ok.
Если вам надо использовать C++ - то CPU обязательно должен иметь MMU.
4) Ограниченное применение из-за отсутствия протокола транспортного уровня поверх TCP (я пробовал делать свой протокол для транспортного уровня, но ушел на WebSockets, впрочем оба решения оказались на порядок лучше голого TCP)
WebSockets считается неликвидным по безопасности. Это не моё мнение, а писателей браузеров...
Вообщем-то, можно и свой вариант развить до версии моста для ESP32, выложить в OpenSource, но пока рановато.
Кто вам мешает? Встройте в него скоростную DRAM, не тормозную SPI RAM, и всё в статике, без heap и будет вам счастье и безотказность, если остальные части чипа позволят :)
 
Сверху Снизу