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

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

Sergey476

New member
меня наверное не совсем правильно поняли.Я не собираюсь создать автопилот для формулы 1 через wifi. В моём случае ( да и в 99%) случаев задержка до 200мс приемлима.Хотя бы потому что объект управления довольно инерционный.
Мне кажется,что мы понятия задержки передачи и скорости передачи объеденяем в одно и из-за этого получается путаница. Если я даже смогу поднять скорость порта GPS приёмника до 115к это не гарантирует уменьшение задержки. Задержка всё равно будет такой-же. я бы был счастлив если удалось гарантировать задежку COM-TCP в 100 мс.
 

pvvx

Активный участник сообщества
меня наверное не совсем правильно поняли.Я не собираюсь создать автопилот для формулы 1 через wifi. В моём случае ( да и в 99%) случаев задержка до 200мс приемлима.Хотя бы потому что объект управления довольно инерционный.
Мне кажется,что мы понятия задержки передачи и скорости передачи объеденяем в одно и из-за этого получается путаница. Если я даже смогу поднять скорость порта GPS приёмника до 115к это не гарантирует уменьшение задержки. Задержка всё равно будет такой-же. я бы был счастлив если удалось гарантировать задежку COM-TCP в 100 мс.
Задержка TCP при передаче малыми редкими пакетами определяется приемной стороной и составляет 200 мс - это привет от Nagle и прочих "разрабоччиков" алгоритмов TCP стека. Модуль не может влиять на алгоритм приемной стороны и уметь предсказывать сколько байт будет принято сейчас по RX и каковы будут задержки между пакетами UART. Подождите лет двести - возможно аналогичным модулям встроят ИИ. :)
Если лить данные в RX с нормальной скоростью, когда передается не менее 2-х пакетов TCP за 200 ms, то задержки нет.
Для устранения задержки в 200ms у приемной стороны используйте специализированные протоколы, парсящие входной и выходной поток UART. Но это не относится к данной теме, т.к. тут простой потоковый передатчик любых данных UART по TCP.
Для таких дел обычно пользуют UDP-RTP
 
Последнее редактирование:

Sergey476

New member
pvvx, спасибо
В общем становится понятно почему многие навигационные программы имеют поддерку как TCP так и UDP. Не подскажете что означают переменные в настройках : TCP recved timeout,TCP close timeout?
И какие значения надо устанавливать? я методом экперемента уставнавил 3 и 3.
 

pvvx

Активный участник сообщества
pvvx, спасибо
В общем становится понятно почему многие навигационные программы имеют поддерку как TCP так и UDP. Не подскажете что означают переменные в настройках : TCP recved timeout,TCP close timeout?
И какие значения надо устанавливать? я методом экперемента уставнавил 3 и 3.
http://yandex.ru/search/?lr=2&text="TCP recved timeout" :) http://esp8266.ru/forum/threads/prozrachnyj-most-wifi-uart-na-esp2866.323/page-2#post-7027
TCP recved timeout: максимальный timeout когда соединение открыто и не передано ничего, до закрытия соединения

TCP close timeout: максимальный timeout после последнего прима-передачи, до закрытия соединения

Client reconnect timeout: время ожидания открытия соединения в случае клиента. Время ответа на запрос соединения перед подачей нового. Зависит от времени пинга туда-обратно + сообразительности запрашиваемого, установленных временных тайм-аутов у обоих. Служит для подбора наиболее быстрого соединения. Оптимальное значение зависит от множества факторов...
 
Последнее редактирование:

Sergey476

New member
У меня UART2TCP работает в качестве сервера и к нему я подключаю клиента gpsbridge. Если на gpsbridge я нажимаю restart, то повторное соединения неудачное.Как я понимаю из-за того что уже открыта одна TCP сесия.Мне кажется было бы удобнее если при попытке открытия второй TCP сесии первая автоматически закрывалась.
 

pvvx

Активный участник сообщества
У меня UART2TCP работает в качестве сервера и к нему я подключаю клиента gpsbridge. Если на gpsbridge я нажимаю restart, то повторное соединения неудачное.Как я понимаю из-за того что уже открыта одна TCP сесия.Мне кажется было бы удобнее если при попытке открытия второй TCP сесии первая автоматически закрывалась.
https://github.com/pvvx/esp8266web/releases
ver046.gif
Путайтесь на здоровье какая сессия открыта последняя, но при DDOS атаке ведет к накоплению структур в памяти с TIME_WAIT на 60 сек...
 
Последнее редактирование:

Sergey476

New member
спасибо pvvx,
но у меня почему то не сохраняются настройки UART, а именно- количество стоповых бит, битов паритета и все галочки, включая мою любимую
 

pvvx

Активный участник сообщества
спасибо pvvx,
но у меня почему то не сохраняются настройки UART, а именно- количество стоповых бит, битов паритета и все галочки, включая мою любимую
Пересоберите и перезалейте диск WEBFiles.bin.
В той прошивке, в WEBFiles.bin забыта, в строке 138 WEBFiles\protect\uart.htm запятая: uart_0_even:"~uart_0_even~", и javascript не работает из-за ошибки.
Тут вроде исправил: fullflash_and_webfs_046_e.zip
 
Последнее редактирование:

Sergey476

New member
Испытываю прошивку 0.4.6e
установил TCP recved timeout:3 сек, TCP close timeoutе :3 сек
Открываю соединение > telnet 192.168.4.1 12345
соединение открывается.
через несколько секунд соединение закрывается.
Теперь открываю соединение и тут-же посылаю по телнету несколько символов.Дальше жду несколько минут.Соединение остаётся открытым и рабочим.
Как я понял из форума,при таких настройках соединение должно закрыться через 3 секунды после
отсуствия передачи данных.Или я опять чтото не понимаю?
 

pvvx

Активный участник сообщества
Как я понял из форума,при таких настройках соединение должно закрыться через 3 секунды после
отсуствия передачи данных.Или я опять чтото не понимаю?
Наверно что-то отвалилось, а я не заметил. Погляжу...
Переменная времени ожидания реконнекта для клиента пишется зачем-то в поле "после отсутствия передачи данных" :) При этом, при старте модуля, без изменения настроек через веб всё работает... Так и было пропущено... Счас поправлю...
Исправлено https://github.com/pvvx/esp8266web/releases
 
Последнее редактирование:

Sergey476

New member
что то у меня наблюдается некоторая нестабильность.
Заливаю прошивку 0.4.6f. В настройках меня только скорость на 4800 и ставлю галку реконект.
дальше с помощью Putty подключаюсть com порту.С помощью другой putty подключаюсь к 192.168.4.1 12345. Соединение устанавливается. Открываю ещё одну putty по 192.168.4.1 12345. Предыдушее окно закрывается.Проделываю это несколько раз .Всё ОК. Дальше переключаюсь между разными окнами putty (com и telnet) и нажимаю клавиши. В другом окне появляются символы.Но через некоторое время всё подвисает. Также в какой-то момент может само закрыться TCP соединение, хотя при таких настройках должно стоять вечно.Через некоторое время при открытии нового соединения , старое соединение не закрывается.
 

pvvx

Активный участник сообщества
что то у меня наблюдается некоторая нестабильность.
Заливаю прошивку 0.4.6f. В настройках меня только скорость на 4800 и ставлю галку реконект.
дальше с помощью Putty подключаюсть com порту.С помощью другой putty подключаюсь к 192.168.4.1 12345. Соединение устанавливается. Открываю ещё одну putty по 192.168.4.1 12345. Предыдушее окно закрывается.Проделываю это несколько раз .Всё ОК. Дальше переключаюсь между разными окнами putty (com и telnet) и нажимаю клавиши. В другом окне появляются символы.Но через некоторое время всё подвисает. Также в какой-то момент может само закрыться TCP соединение, хотя при таких настройках должно стоять вечно.Через некоторое время при открытии нового соединения , старое соединение не закрывается.
Т.е. уже благополучно запутались - "Путайтесь на здоровье какая сессия открыта последняя" :)
Конкретнее можно описать?
Старое соединение может не закрываться по причине putty оказавшейся закрыть соединение по приходу команды закрытия (представим, что не дошел пакет). Повторов и реакция ограничены, далее делается abort соединения... Вроде для исключения этого бардака и вводятся тайм-ауты...
Вы уверены что ваша putty не написана в детсаде?
Частный случай проверьте - сделайте одно соединение и отключите питание модуля :)
Putty скажет что коннект до сих пор есть ? :) Через сколько секунд она сообразит, что "всё пропало" ?
 
Последнее редактирование:

Sergey476

New member
putty написано в этом детсаде : https://ru.wikipedia.org/wiki/PuTTY
1.если я выключаю модуль esp8266, то окно закрывается через три секунды.
2.если я подключаюсь через putty к домашнему роутеру и даю роутеру команду reboot , то окно закрывается мгнвенно.
3.Если я подключаюсть через putty к удалённому устройству через интернет и канал интернет рвётся, то putty может висеть долго. Но если я пытаюсь послать на удалённое устройство что либо, то putty видит отсуствие соеденения и через несколько секунд закрывается.

Вообще я готов пользоваться любыми пограмами, которые вы скажете.
 

Tomahawk

New member
Sergey476, что вы хотите получить от программы, версия которой 0.65? :) даже сами авторы не гарантируют, что она будет 100% верно работать. Вы сейчас проводите какие-то эксперименты, смысл которых я пока не понял. Опишите, чего вы хотите добиться в терминах сервер-клиент, кто куда должен подключаться и что слать. А так, когда там закрывается "окно", это зависит от того, каким образом написана сама Putty.
 

Sergey476

New member
Sergey476, что вы хотите получить от программы, версия которой 0.65? :) даже сами авторы не гарантируют, что она будет 100% верно работать. Вы сейчас проводите какие-то эксперименты, смысл которых я пока не понял. Опишите, чего вы хотите добиться в терминах сервер-клиент, кто куда должен подключаться и что слать. А так, когда там закрывается "окно", это зависит от того, каким образом написана сама Putty.
Не надо судить о программе по её номеру версии.Гарантию вообще никто никогда не даёт, тем более на бесплатный продукт.
Смысл эксперемента в следующем:
1. Имеется сервер esp8266
2. Имеется клиент 1 (putty1)
3.Имеется клиент 2 (putty2)
Включаем сервер. Клиент 1 устанавливает соединение с сервером. Ок.Теперь клиент 2 пытается установить соединение с сервером. Соединение с клиентом 1 разрывается по инициативе сервера и устанавливается соединение с клиентом 2. Теперь снова клиент 1 пытается соедениться.Соединение с клиентом 2 разрывается и устанавливается с клиентом 1. И так можно до бесконечности. Все работает как задумано.
Усложняем эксперемент. Клиент 1 соеденяется с сервером начинает посылать данные ( коды аски с клавиатуры) на сервер. На ком порту сервера появляются эти данные.Теперь посылаем данные (коды аски с клавиатуры) на ком порт сервера. Данные появлятся на выходе клиента 1.запускаем клиента 2.Соединение с клиентом 1 рвётся. Посылаем данные на ком порт сервера ,они появляются на выходе клиента 2.Посылаем данные на с клиента 2 , они появлятся выходе ком порта сервера. Вроде всё нормально. Но если эту процедуру со сменой клиентов повторять дальше и увеличивать количество передаваемых символов, то наблюдается некокое зависание. Выражающее в том, что при установлении соединение с новым клиентом соединение со старым не рвётся.Также почему то при установленном соединении данные с ком порта сервера не появляются на клиенте.Также иногда наблюдается разрыв соединения клиент сервер, хотя исходя из настроек соединение должно держаться вечно.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Не надо судить о программе по её номеру версии.Гарантию вообще никто никогда не даёт, тем более на бесплатный продукт.
Смысл эксперемента в следующем:
1. Имеется сервер esp8266
2. Имеется клиент 1 (putty1)
3.Имеется клиент 2 (putty2)
Включаем сервер. Клиент 1 устанавливает соединение с сервером. Ок.Теперь клиент 2 пытается установить соединение с сервером. Соединение с клиентом 1 разрывается по инициативе сервера и устанавливается соединение с клиентом 2. Теперь снова клиент 1 пытается соедениться.Соединение с клиентом 2 разрывается и устанавливается с клиентом 1. И так можно до бесконечности. Все работает как задумано.
Усложняем эксперемент. Клиент 1 соеденяется с сервером начинает посылать данные ( коды аски с клавиатуры) на сервер. На ком порту сервера появляются эти данные.Теперь посылаем данные (коды аски с клавиатуры) на ком порт сервера. Данные появлятся на выходе клиента 1.запускаем клиента 2.Соединение с клиентом 1 рвётся. Посылаем данные на ком порт сервера ,они появляются на выходе клиента 2.Посылаем данные на с клиента 2 , они появлятся выходе ком порта сервера. Вроде всё нормально. Но если эту процедуру со сменой клиентов повторять дальше и увеличивать количество передаваемых символов, то наблюдается некокое зависание. Выражающее в том, что при установлении соединение с новым клиентом соединение со старым не рвётся.Также почему то при установленном соединении данные с ком порта сервера не появляются на клиенте.Также иногда наблюдается разрыв соединения клиент сервер, хотя исходя из настроек соединение должно держаться вечно.
При закрытии соединения не переданные данные из буферов выкидываются (теряются). LwIP не может закрыть соединение, если у него заполнен буфер приема, который не обработан (менялось окно приема, т.к. скорость слива UART значительно менее TCP). Ситуация неоднозначная и простого выхода из неё нет - только через abort соединения, что не очень корректно. При создании нового соединения ждите конца передачи данных в UART и всё будет OK.
Подстраивать алгоритмы под ваши программы и скорость UART я не собираюсь. Это частный случай, тем более работа с UART у вас ведется некорректно - не используются RTS/CTS.
Увеличьте скорость работы UART и все неоднозначности будут проявляться меньше, пропорционально к приближению скорости UART к 3MBaud.
 
Последнее редактирование:

Sergey476

New member
В предыдущем моём посте расписан по просьбе Tomahawk, сделаный тест.Это самый простой тест,который делается пользователем с конвертером rs232 -TCP. Т.е с одной стороне к последовательному порту подключается терминал, а с другой стороны через IP сеть терминальная оболочка. На терминале нажимаются клавиши и смотрятся что-бы буковки появлялись на терминальной оболочке. На терминальной оболочке нажимаются клавиши и смотряться как они появляются на терминале.Далее рвётся IP канал между терминалом и терминальной оболочкой и пытаемся востановить соединениеи снова начать обмениваться буковками. Этот тест проходят большинство конвертеров RS232 в TCP.И по идее должен пройти и EPS8266. Но он почему то произвольно разрывает соединение, а также в какойто момент прекращается передача буковок.
При закрытии соединения не переданные данные из буферов выкидываются (теряются). LwIP не может закрыть соединение, если у него заполнен буфер приема, который не обработан (менялось окно приема, т.к. скорость слива UART значительно менее TCP).
В данном тесте скорость передачи(нажатия буковок) 10 байт/c сомневаюсть что такую скорость сложно выдать через ком порт на скорости 4800 , а так же через wifi 802.11n.
Ситуация неоднозначная и простого выхода из неё нет - только через abort соединения, что не очень корректно. При создании нового соединения ждите конца передачи данных в UART и всё будет OK.
я не програмист,но наверное можно остаток отправить вместо UART в подобиее NULL
Подстраивать алгоритмы под ваши программы и скорость UART я не собираюсь. Это частный случай, тем более работа с UART у вас ведется некорректно - не используются RTS/CTS.
В тестах я не использую собственных программ, кроме того я пытаюсь использовать наиболее популярные программы.Я не придумываю ничего нового, я просто переношу идеи реализованные в конвертерах RS232-ethernet в ваш конвертер.Мне непонятно почему при обмене со скоростью 10 буковок в сеукунду ещё нужны RTS/CTS. Какие буфера могут переполниться?
Увеличьте скорость работы UART и все неоднозначности будут проявляться меньше, пропорционально к приближению скорости UART к 3MBaud.
Если я даже увеличу скорость UART до 3M, это не изменит ситуацию т.к. нажимать кнопки на клавиатуре чаще 10 раз в секунду я не смогу и прерывания у ва будут с такойже частотой как и на скорости 4800.

PS скажите какая по вашему терминальная программа хорошая и я на ней буду проводить тестирование. И даже по вашей любой методике.
 

pvvx

Активный участник сообщества
В предыдущем моём посте расписан по просьбе Tomahawk, сделаный тест.Это самый простой тест,который делается пользователем с конвертером rs232 -TCP. Т.е с одной стороне к последовательному порту подключается терминал, а с другой стороны через IP сеть терминальная оболочка. На терминале нажимаются клавиши и смотрятся что-бы буковки появлялись на терминальной оболочке. На терминальной оболочке нажимаются клавиши и смотряться как они появляются на терминале.Далее рвётся IP канал между терминалом и терминальной оболочкой и пытаемся востановить соединениеи снова начать обмениваться буковками. Этот тест проходят большинство конвертеров RS232 в TCP.
Не заметил. Вопрос уже был задан: отключите питание у модуля на ходу - через сколько времени ваша putty сообразит об обрыве связи?

И по идее должен пройти и EPS8266. Но он почему то произвольно разрывает соединение, а также в какойто момент прекращается передача буковок.
Что должно пройти? Попробуйте соединить разные программы терминалов и потестировать :)

В данном тесте скорость передачи(нажатия буковок) 10 байт/c сомневаюсть что такую скорость сложно выдать через ком порт на скорости 4800 , а так же через wifi 802.11n.

я не програмист,но наверное можно остаток отправить вместо UART в подобиее NULL
Дык вы спрашивали куда деваются буковки при пересоединении. Удаляются из буфера.

В тестах я не использую собственных программ, кроме того я пытаюсь использовать наиболее популярные программы.Я не придумываю ничего нового, я просто переношу идеи реализованные в конвертерах RS232-ethernet в ваш конвертер.Мне непонятно почему при обмене со скоростью 10 буковок в сеукунду ещё нужны RTS/CTS. Какие буфера могут переполниться?
А как вы определяете наличие соединения и куда уходят данные буковки если его нет? :)
Т.е. смысл TCP теряется.

Если я даже увеличу скорость UART до 3M, это не изменит ситуацию т.к. нажимать кнопки на клавиатуре чаще 10 раз в секунду я не смогу и прерывания у ва будут с такойже частотой как и на скорости 4800.
нет не будут. За время передачи символа на 4800 может произойти несколько переключений соединения :)

PS скажите какая по вашему терминальная программа хорошая и я на ней буду проводить тестирование. И даже по вашей любой методике.
У меня нет методики, но известно как работает TCP. С этого и берется алгоритм.
Начните с установки соединения. Какая программа из разных, даже при одинаковом времени старта последняя получит соединение зависит от сети и её расторопности (алгоритмов работы и запрашиваемых ресурсов у контролеров) + случайное число (распределение процессов).
Если кто-то написал кривой неоднозначный алгоритм, но который нравится вам по каким-то критериям, то почему я должен повторять его? :)
Ещё, к примеру, в SDK есть опция сбрасывать TIME_WAIT, что недопустимо для стандарта TCP, но вставлено т.к. китайцам так было проще решить вопрос переполнения малой памяти ESP8266. Я должен учитывать такие глюки, если пользователь установит этот флаг? (он есть в системных переменных на веб). Ну и т.д., типа кривой реализации малого потребления WiFi у китайцев за счет насилования LwIP (увеличения периода таймера опроса соединений в LwIP со стандартных 25 ms на 3000 ms. От этого завсият и счетчики тай-аутов соединения...) :)
Так что всё в руках пользователя - ему дана возможность извращения как понравится. :)
PS: Алгоритмы TCP стека Микрософт не позволяют передать более 5-ти пачек по пару байт за 1 сек. По тому их експлорер имеет собственный стек TCP, а другие вечно нарываются на данное ограничение :) По этой и другой причине большинство вопросов адресуйте туда, а не ко мне. Когда найдете решение и перевернете мир, то я с удовольствием вставлю поправки, тем более исходники данной свалки вам даны. :)
 
Последнее редактирование:

Sergey476

New member
Не заметил. Вопрос уже был задан: отключите питание у модуля на ходу - через сколько времени ваша putty сообразит об обрыве связи?
вообщето уже ответил в посте 253
Что должно пройти? Попробуйте соединить разные программы терминалов и потестировать :)
мне нравтиться putty, назовите которая у вас вызывает доверие.Я то мне перебрать все существующие программы эмуляторов терминала- жизни нехватит.
Дык вы спрашивали куда деваются буковки при пересоединении. Удаляются из буфера.
Это я понимаю, просто при повторном пересоединении может быть только односторонняя передача или появляется локальное эхо.К потерянным буковкам при пересоединении притензий не будет.
А как вы определяете наличие соединения и куда уходят данные буковки если его нет? :)
Т.е. смысл TCP теряется.
непонял вопроса. У меня первое окно подключено к ком порту.Открываю второе окно и соеденяюсь по IP нажимаю кнопочки,смотрю как в другом окне появляются буковки. открываю третье окно и соеденяюсь по IP. Второе окошко исчезает т.к. соединение TCP разрывается.Теперь пересылаю буковки между первым (сом) и третьем. Потом открваю четвертое и т.д. По идее это можно проделывать до бесконечности. Но после очередного раза передача буковок становится односторонняя и предыдушие окошки не закрываются.
нет не будут. За время передачи символа на 4800 может произойти несколько переключений соединения :)
несогласен,но спорить не буду.скорость 115200 -устроит?
У меня нет методики, но известно как работает TCP. С этого и берется алгоритм.
Начните с установки соединения. Какая программа из разных, даже при одинаковом времени старта последняя получит соединение зависит от сети и её расторопности (алгоритмов работы и запрашиваемых ресурсов у контролеров) + случайное число (распределение процессов).
Если кто-то написал кривой алгоритм, но который нравится вам, то почему я должен повторять его? :)
Наверное потому что мы хотим чтобы программа хорошо работала и нравилась пользователям.
Модули Tibbo уже более десятка лет все используют и проиведены они милионами.Может у них позаимствовать основные сомнительные моменты.
 
Последнее редактирование:

pvvx

Активный участник сообщества
вообщето уже ответил в посте 253
Там и показано, что Putty не знает, что соединение больше нет. Обычная типичная конфигурация у TCP2UART - модуль соединен к местному AP (роутеру) и комп тоже.
Модули Tibbo уже более десятка лет все используют и проиведены они милионами..
На счет пару тысяч даже не согласен :) Тем более всё зависит от альтернативы.
Может у них позаимствовать основные сомнительные моменты.
Всё и так работает. Ничего заимствовать не требуется.
Наверное потому что мы хотим чтобы программа хорошо работала и нравилась пользователям.
А у меня нет такой цели. Одна из главных тут целей - разработать технически правильные методы и алгоритмы работы для ESP8266. Она не пересекается с исправлениями putty и другого стороннего ПО понравившегося народу. Причина в том, что народ всегда выбирает самое плохое техническое решение и всё зависит исключительно от рекламы.
 
Последнее редактирование:
Сверху Снизу