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

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

Tomahawk

New member
Наверное потому что мы хотим чтобы программа хорошо работала и нравилась пользователям.
А мне итак пока всё нравится. В данный контроллер портирована LwIP, которая поднимает TCP-соединение и используется практически на всех встраиваемых системах в мире - проблем с ней я не обнаружил, работает как надо. Я спрашивал вас о сервере-клиенте для того, чтобы понять, знаете ли вы о событиях, которые происходят в ТСР-соединении, sent или disconnect, например. Сервер и клиент должны договариваться между собой, а как реагирует Putty-клиент на команды сервера вы не знаете. Если там что-то происходит неправильно, это проблемы конкретной программы, что уже обсуждалось в [HASHTAG]#252[/HASHTAG] сообщении.
мне нравтиться putty, назовите которая у вас вызывает доверие.Я то мне перебрать все существующие программы эмуляторов терминала- жизни нехватит.
Мы же как-то нашли, и остальные тоже их находят как-то по отдельности, почему вы не можете? Самая лучшая программа для работы с СОМ-портом называется Terminal v1.9b, для работы с ТСР, когда нужно было поднять сервер через lwip на МК, я использовал Hercules 3.2.8. Вперёд, изучайте )
 
Последнее редактирование:

Sergey476

New member
Tomahawk, очень хорошо,что нравится и у вас прекрасно работает.Опишите схему использования, и сколько времени работает схема. Это будет полезно новичкам и мне. У мне есть еще ряд проблем, и мне интересно проявляются ли они у вас (0.4.6f):
1. пропадает приблизительно 1 % пингов, если есть маленький поток данных через UART (200 байт/c).
2. при настройке 802.11n мой компьютер показывает наличие только b g.
3. если в веб интерфейсе сменить режим с 802.11n на 802.11g ,то пересоединения не происходит .т. е. точка доступа появляется, но компьютер к ней подсоедениться не может.Помогает только сброс питания ESP.
Для меня Putty это инструмент тестирования модуля. Я его выбрал т.к. он бесплатный и им пользуются милионы системных администраторов для управления удалёнными серверами. Но к сожалению данную программу не признаёт главный разработчик, поэтому проводить тестирование на других программах бесмысленно, пока эту программу не одобрил разработчик.
Я описал простейшую методику тестирования (с 3-х разных сторон),но мне никто не сказал что в ней неправильно, кроме предположений что Putty г....Менять на другую программу о которой скажут тоже самое не имеет смысла.
Поэтому дальнейшее тестирование я буду проводить на USR-TCP232-test
 
Последнее редактирование:

pvvx

Активный участник сообщества
Для меня Putty это инструмент тестирования модуля. Я его выбрал т.к. он бесплатный и им пользуются милионы системных администраторов для управления удалёнными серверами.
Серверами, но не TCP2UART. Для этого есть множество другого ПО. И как ни странно, чем в них используются более классические подходы работы с TCP, тем лучше. В итоге множество встроенных терминалов к примеру на Java или Python и типа работают корректнее, т.к. не лезут управлять TCP стеком самостоятельно...
Я описал простейшую методику тестирования (с 3-х разных сторон),но мне никто не сказал что в ней неправильно, кроме предположений что Putty г....Менять на другую программу о которой скажут тоже самое не имеет смысла.
Тестирование производилось разным ПО, в том числе самописным.
Поэтому дальнейшее тестирование я буду проводить на USR-TCP232-test
Она не умеет работать с сигналами RTS/CTS и не понимает закрытия окна TCP (при передаче в ней не проверятся отправка пакетов).
 
Последнее редактирование:

Sergey476

New member
Там и показано, что Putty не знает, что соединение больше нет. Обычная типичная конфигурация у TCP2UART - модуль соединен к местному AP (роутеру) и комп тоже.
На счет пару тысяч даже не согласен :) Тем более всё зависит от альтернативы.

Всё и так работает. Ничего заимствовать не требуется.
А у меня нет такой цели. Одна из главных тут целей - разработать технически правильные методы и алгоритмы работы для ESP8266. Она не пересекается с исправлениями putty и другого стороннего ПО понравившегося народу. Причина в том, что народ всегда выбирает самое плохое техническое решение и всё зависит исключительно от рекламы.
Не буду вступать в абстрактную дискусию т.к. это неконструктивно.
Взял программу USR-TCP232 , в настройках поменял режим на TCP клиент, поставил интервал задержки 100мс. остальное по умолчанию.Прошивка 0.4.6f
Нажимаю снизу кнопки send то справо то слево. то часто ,то редко, то даю паузу несколько секунд.Раз на 50-й всё виснит .Т.е. нажимаю клавиши send, но на экране ничего не появляется.Иногда соединение разрывается. Если запустить непрерывную передачу слево и справо , то ничего не виснит.
Это так и должно быть?
 

pvvx

Активный участник сообщества
Не буду вступать в абстрактную дискусию т.к. это неконструктивно.
Взял программу USR-TCP232 , в настройках поменял режим на TCP клиент, поставил интервал задержки 100мс. остальное по умолчанию.Прошивка 0.4.6f
Нажимаю снизу кнопки send то справо то слево. то часто ,то редко, то даю паузу несколько секунд.Раз на 50-й всё виснит .Т.е. нажимаю клавиши send, но на экране ничего не появляется.Иногда соединение разрывается. Если запустить непрерывную передачу слево и справо , то ничего не виснит.
Это так и должно быть?
Без RTS/CTS никаких гарантий работоспособности для TCP2UART нет.
И того, что описываете, у меня нет и не проявляется, кроме частичной потери данных в USR-TCP232 из-за описанных причин в ней в прошлом посту.
Да и версия уже 0.4.7 давно :) Там 'улучшено' (а может ухудшено :) ) закрытие соединения в случае реконнекта...
PS: Не понятна странность проверять TCP через какие-то программы с неизвестным поведением. Возьмите Wireshark и приведите лог, где возникает ошибка. Иначе ваши разговоры не о чем, типа что-то там на обратной стороне Луны...
 
Последнее редактирование:

pvvx

Активный участник сообщества
@Sergey476 Методика проверки такая:

Подключаете все 4 линии RX/TX/CTS/RTS к ESP8266.
Включаете два RS-TTL порта – один на RX/TX/CTS/RTS, другой для снятия лога через debugTX.
Желательно на линии RX/TX/CTS/RTS включить логический анализатор для уверенности , что ПО работающее с COM портом работает правильно.
Включаете Wireshark на соединение.
Запускаете тестовое ПО и снимаете все логи. В случае ошибки исследуете логи и публикуете кусок связанный с ней с описанием предистории и т.д.
Я делал именно так и использовал разное ПО... Багов в нем мульоны... 100% работающего ПО по стандартам TCP и прочим связанным с данной темой пока не найдено - у каждого свои причуды и ошибки.
PS: И ещё раз о putty и типа – это софт для работы с ней человека, который знает причуды TCP стеков, местных коммуникационных “линий” и условий на них, и т.д. :) Она никогда не использовалась для автоматической связи в пром. установках – от этого у неё другой подход. Оно рассчитывает, что вы являетесь оператором и в некоторых случаях сами исправите ошибочную ситуацию (к примеру если сервер отвалился по причине массовых помех на линии, т.к. сварщик решил варить трубу рядом с работающим сервером, что очень близко по состоянию связи на WiFi в крупных городах :) ).
Не забудьте провести тест TCP2UART через внешние proxy, чтобы сигнал огибал шарик через всевозможные линии инет (включая GSM) и имел пинг в несколько секунд.
 
Последнее редактирование:

Sergey476

New member
pvvx, постараюсь быть краток.
1.основная проблема в текущей версии, что происходит подвисание т.е. прекращение передачи данных между UART и клиентом TCP. Причин может быт много: ошибки в драйвере UART, ошибки в стеке TCP, переменные наезжают друг на друга ,поднимются RTS,CTS когда не надо и т.д.Без обеспечения надёжного преобразования UART-TCP на разных скоростях и при разной нагрузке двигаться дальше не имеет смысла. Даже при неподкюченых rts cts ничего виснуть не должно. Возможно потеря части данных а не подвисание соединения.
2.Я провел много тестов с различными программами, даже использовал вами используемую при тестировании.Мне удалось обнаружить некоторые баги,наиболее критичный- подвисание.В каждом случае вы считаете что виновата тестирующая программа и отравляете на просторы интернета , предлагаете всё более сложные схемы тестирования. Я предполагаю ,что в более сложных схемах будет ещё больше нареканий на тестирующее ПО и схемы будут всё сложнее и сложнее.Переубедить вас мне не удастся.
3.Мне очень нравиться ваша программа, но к сожалению я считаю что в ней (или в китайских подпрограммах) есть критические баги не позволяющие её использовать в предполагаемых приложениях.
4.Я готов принимать участие в тестировании, если будет понятно что и как тестировать и это будет вам нужно.
5.Для моего конкретного GPS использования мне проще и надёжней протянуть сигнал RS232 на роутер под OpenWrt и с него раздавать NMEA0183 по TCP одновременно на несколько устройств.
 

pvvx

Активный участник сообщества
pvvx, постараюсь быть краток.
1.основная проблема в текущей версии, что происходит подвисание т.е. прекращение передачи данных между UART и клиентом TCP. Причин может быт много: ошибки в драйвере UART, ошибки в стеке TCP, переменные наезжают друг на друга ,поднимются RTS,CTS когда не надо и т.д.Без обеспечения надёжного преобразования UART-TCP на разных скоростях и при разной нагрузке двигаться дальше не имеет смысла. Даже при неподкюченых rts cts ничего виснуть не должно. Возможно потеря части данных а не подвисание соединения.
У меня по нескольку суток работало без перерыва TCP2UART с собственным ПО. Делалось это для диагностики - сохранения логов. Багов не было.
Так-же использовал для работы со своим COM-СAN контролером (там постоянно идет связь туда-сюда мелкими пакетами) - всё успешно.
2.Я провел много тестов с различными программами, даже использовал вами используемую при тестировании.Мне удалось обнаружить некоторые баги,наиболее критичный- подвисание.В каждом случае вы считаете что виновата тестирующая программа и отравляете на просторы интернета , предлагаете всё более сложные схемы тестирования. Я предполагаю ,что в более сложных схемах будет ещё больше нареканий на тестирующее ПО и схемы будут всё сложнее и сложнее.Переубедить вас мне не удастся.
Вами пока не дано конкретики - имеем просто спам, типа оно "подвисает" при "моих тестах". :) Т.е. совершенно не известно причина ваших "подвисаний" и её связь. Возможно она связана с вашим роутером, т.к. выяснилось что он даже на 802.11n работать не может, а возможно и с компом... Гадать больше никто не собирается - укажите четкую ситуацию с логами.
ЗЫ: На OpenWRT у вас просто так не выйдет TCP2UART. Там достаточно сложно убрать все системные сообщения с единственной UART у наиболее часто встречаемых системах на AR9331. Проблеммы возникают даже если поставить внешний микроконтроллер со связью по SPI. SPI там тоже одна на Flash и всё остальное... Если на I2S переходить для связи с внешним UART, то потянет. Но думаю с этим не справитесь, да и как-то криво...
 
Последнее редактирование:

Sergey476

New member
У меня по нескольку суток работало без перерыва TCP2UART с собственным ПО. Делалось это для диагностики - сохранения логов. Багов не было.
Какая версия прошивки была ? Вы наверное с тех времён уже всё заново переписали.Да и китайцы библиотеки переписали. Скинте ту версию , я потестирую.Может в ней всё хорошо с моей точки зрения.
Так-же использовал для работы со своим COM-СAN контролером (там постоянно идет связь туда-сюда мелкими пакетами) - всё успешно.
Вы искажаете мою мысль. Я говорил о том что подвисание наблюдается когда данные иду неравномерно, с перерывами.Это не тоже самое что часто маленькими пакетами.
Вами пока не дано конкретики - имеем просто спам, типа оно "подвисает" при "моих тестах". :)
Я один и тотже тест описал три раза разными словами. Тот же тест специально провёл на используемой вами программе. У вас одни отговорки: то программа неправильная, то rts,сts не заведён. Значит дальше буду снимать видеоролики.
У нас с вами разные цели тестирования , я хочу провести тест так что бы найти большее количество багов, а вы что бы убедиться что работает.
Т.е. совершенно не известно причина ваших "подвисаний" и её связь. Возможно она связана с вашим роутером, т.к. выяснилось что он даже на 802.11n работать не может, а возможно и с компом... Гадать больше никто не собирается - укажите четкую ситуацию с логами.
Ну конечно boadcom чип на все wifi точки пишет что есть N, а на вашу нет. Значит броадком неправильно работает. С какими логами, что TCP2UART выдаёт каке-то логи? Или я должен обвешать всё анализатрорами и программами, название которых вы даже не раскрываете.
ЗЫ: На OpenWRT у вас просто так не выйдет TCP2UART. Там достаточно сложно убрать все системные сообщения с единственной UART у наиболее часто встречаемых системах на AR9331. Проблеммы возникают даже если поставить внешний микроконтроллер со связью по SPI. SPI там тоже одна на Flash и всё остальное... Если на I2S переходить для связи с внешним UART, то потянет. Но думаю с этим не справитесь, да и как-то криво...
Вы искажаете мою задачу. Я писал об подключении GPS приёмника для передачи координат.Поэтому мне неважно что на выходе ком порта.Интересует только вход. И раздавать я смогу не только одно устройство, а на несколько TCP сесий.Я это не сделал т.к. не хотел тянуть лишний провод .Да и начитался в интернете какая хорошая программа TCP2UART. Я если понадобится полноценный TCP2UART, то включу просто USB-COM в роутер. Надо пытаться проще решить задачу.
 

pvvx

Активный участник сообщества
Я один и тотже тест описал три раза разными словами. Тот же тест специально провёл на используемой вами программе. У вас одни отговорки: то программа неправильная, то rts,сts не заведён. Значит дальше буду снимать видеоролики.
У нас с вами разные цели тестирования , я хочу провести тест так что бы найти большее количество багов, а вы что бы убедиться что работает.
У меня не получается воспроизвести описываемое вами "зависание", по тому и гадалки.
К примеру просто отсылка в две стороны (TX/RX) пару символов c указанными вами задержками работает уже пару часов и без RTS/CTS в программе USR-RS232:
ttt.gif
Потерь нет, т.к. скорость низкая и модуль рядом, не через длинный путь...
RTS/СTS требуется для передачи и приема без потерь информации что-бы не зависеть от внешних условий.
Переключение в разные окна, как в видео
работают как не тыкайся. Но, зная алгоритм, известно, что если модуль будет закрывать TCP соединения очень часто, то в памяти на 60 сек накапливаются структуры pcb пусть будет примерно в 100 байт. Heap у нас 40 килобайт. При открытии нового соединения проверяется минимум на 16 килобайт. Итого вы должны создать условия для более 240 реконнектам за 60 секунд, чтобы новый временно не открылся. Так я не умею и не хочу долбить по клаве в putty :) Для наглядности, когда будите долбить, включите показ графика "heap" - Debug and Test -> Chart 'heap'

Логи дает модуль во второй порт UART.
ЗЫ: Пока опять идет один спам. Нуль технической информации... :)
Очень похоже, что у вас модуль плохо запитан и перезагружается. Так-же учтите, что существует куча случаев продажи китайцами кривых микросхем ESP8266, частичную диагностику можно произвести измерив потребление модулем по питанию (ссылки на практически все режимы работы указаны тут). В режиме Web жрет 71 мA (с выключенными sleep WiFi : NONE и включенным 160MHz CPU) без передачи, при передаче среднее менее 170 мА. 100% правильно включенный модуль в режиме программирования, но прошивку не заливаем, потребляет 32..33 мА (перед включением и замером требуется снять питание и включить модуль с подтяжками в режим программирования). Описания как мучаются с кривыми ESP8266 можете найти на сайте...
Только лог нам поможет. :)
 
Последнее редактирование:

Sergey476

New member
pvvx,
1. на какой скорости принимать лог?что делать с логом?прислать вам?
2. для того что бы обнаружить случайные перезагрузки в люникс системах есть таймер, который считает время с последнего рестарта.его можно всегда посмотреть.
3.в версии 0.4.7 координальных улучшений не заметил.
 

pvvx

Активный участник сообщества
pvvx,
1. на какой скорости принимать лог?что делать с логом?прислать вам?.
Показать тут ту часть, где произошел сбой.
2. для того что бы обнаружить случайные перезагрузки в люникс системах есть таймер, который считает время с последнего рестарта.его можно всегда посмотреть.
В данном Web сервере их несколько и все можно посмотреть (вывести на веб страницы и т.д. - редактор диска с файлами дан)
3.в версии 0.4.7 координальных улучшений не заметил.
На перезагрузку модуля от кривого питания это не влияет :)
 
Последнее редактирование:

Sergey476

New member
В данном Web сервере их несколько и все можно посмотреть (вывести на веб страницы и т.д. - редактор диска с файлами дан)
Ответ понятен - сейчас нет, но каждый может сделать самостоятельно если ему это нужно.
На перезагрузку модуля от кривого питания это не влияет :)
Нашли нового виновника - кривое питание, тем более пока счётчики невидны всё можно валить на питание.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Нашли нового виновника - кривое питание, тем более пока счётчики невидны всё можно валить на питание.
Они видны, и есть даже менюшки для их вызова. Беда пока только в ваших знаниях, т.к. проблема питания подходит под ваши описания на 100%. В начале я даже не думал про это, т.к. считал что это вы проверили в первую очередь. Но теперь очень сомневаюсь... :)
 

Sergey476

New member
Я ещё раз обрисую ситуацию:
Версия 0.4.7.Тесты с USR-TCP232 Проходят успешно , 15 минут передаются данные без ошибок и зависаний. Количество переданных и принятых байт соответственно равны. Работает на скорости как 115200 так и 4800.
Если передавать посимвольно( с клавиатуры ) с различными паузами, с разной стороны, то через некоторое время возникает подвисание (отсуствие передачи данных в обе стророны ).Лечится пересоединением TCP.Проявляется как на программе USR-TCP232 так и Putty.Также проявляется при их комбинации.
Они видны, и есть даже менюшки для их вызова. Беда пока только в ваших знаниях, т.к. проблема питания подходит под ваши описания на 100%. В начале я даже не думал про это, т.к. считал что это вы проверили в первую очередь. Но теперь очень сомневаюсь... :)
Да да да.Именно проблема питания проявляется при редкой передаче данных. Наверное процесор сходит с ума от безделия. Притом только в части UART-TCP, т.к. веб работает без ошибок. К сожалению для пользования TCP2UART только один человек имеет необходимые знания. Если бы конструкторы мерседеса делали машину, которой могли пользоваься только они,то наверное это был бы не мерседес.
 
Последнее редактирование:

FGX

Member
Я ещё раз обрисую ситуацию:
Добрый день. Скорость лога настраивается в форме Скриншот 2015-09-19 22.36.29.png
Сделайте вы наконец лог работы, что вам стоит подключить к выходу GPIO2 еще один преобразователь уарт в виртуальный com порт? К тому выложите тогда еще и все скриншоты настройки модуля.
PS. Странно, что вы не знаете о возможности вести лог и скорости его настройки, возможно вы повключали энергосберегающие режимы нечаяно или еще что...
 

pvvx

Активный участник сообщества
Именно проблема питания проявляется при редкой передаче данных. Наверное процесор сходит с ума от безделия. Притом только в части UART-TCP, т.к. веб работает без ошибок. К сожалению для пользования TCP2UART только один человек имеет необходимые знания. Если бы конструкторы мерседеса делали машину, которой могли пользоваься только они,то наверное это был бы не мерседес.
Опять лирика.
Сели бы и написали Help для всех. Я не журналист и не имею времени и желания для художественного описания системы для людей с нулевыми знаниями по данной тематике.
Редкая передача работает и проверена. На неё могут влиять включенные грин-режимы к примеру у роутера и других компонентов по линии связи до модуля.
Лечится пересоединением TCP.
На то и существуют тай-ауты. Не все системы могут держать постоянно открытым канал. К примеру при NAT - ему логика не позволит.
Модуль и его TCP2UART тут не причем и он работает стабильно. От "грин" систем сказывается только время первого пинга после продолжительной паузы.
Если в вашей putty нет установки тайм-аутов, то обычно это говорит что используется механизм автоматического пересоединения. Если его нет - значит пишите авторам вашей putty...
Ну и по поводу художественной литературы :) - ничего не может быть вечного, кроме самой вечности.
Если бы конструкторы мерседеса делали машину, которой могли пользоваься только они,то наверное это был бы не мерседес.
Действительно - обезьяна не способна управлять мерседесом без обучения, как и любой человек.
 
Последнее редактирование:

Sergey476

New member
Добрый день. Скорость лога настраивается в форме Посмотреть вложение 902
Сделайте вы наконец лог работы, что вам стоит подключить к выходу GPIO2 еще один преобразователь уарт в виртуальный com порт? К тому выложите тогда еще и все скриншоты настройки модуля.
PS. Странно, что вы не знаете о возможности вести лог и скорости его настройки, возможно вы повключали энергосберегающие режимы нечаяно или еще что...
О наличии порта на который могут отсылаться логи я знаю. Но я не знаю что на него выводится и что ещё решил выводить разработчик. Я также не знаю какая скорость логирования разработчик считает достаточной. Я сделаю лог, но всё что мы из него узнаем - это что модуль не перезагружается.При тестировании я заливаю прошивку и меняю только настройку скорости порта. Поэтому поменять ещё что либо я не мог. Если у вас есть желание улучшить программу, то проведите тест с putty, о котором я писал. Если ничего не зависает,так и напишите.Будем считать что у меня кривые руки и кривой модуль.
PS. Сейчас меня беспокоит только то,что новички на форуме будут пытаться использовать прошивку и когда у них будут проблемы искать свою ошибку, и не предполагать что это фишка или баг прошивки.
 
Последнее редактирование:

Sergey476

New member
вот лог для прошивки 0.4.7, GPIO2,4800
Включается модуль и к нему подключён по wifi ноутбук. Ничего больше не подключается и не передаётся. Последние пачки сообщений повторяются стабильно с периодом около 60 секунд. Если с периодом раз в 10 секунд при установленном TCP соединении посылать один байт в направлении ком порта,то сообщения в логах не появляются.
всё снято программой USR-tcp232
 

Вложения

pvvx

Активный участник сообщества
вот лог для прошивки 0.4.7, GPIO2,4800
Включается модуль и к нему подключён по wifi ноутбук. Ничего больше не подключается и не передаётся. Последние пачки сообщений повторяются стабильно с периодом около 60 секунд. Если с периодом раз в 10 секунд при установленном TCP соединении посылать один байт в направлении ком порта,то сообщения в логах не появляются.
всё снято программой USR-tcp232
Ну вот и лог и ответ:
У вас кто-то постоянно отключает соединение и меняется IP адрес каждые несколько секунд. :)
Происходят события EVENT_STAMODE_DHCP_TIMEOUT: WiFi event 4, потом WiFi event 5 = EVENT_SOFTAPMODE_STACONNECTED
Переведите сообщения :) :
Station[1]: <mac> join, AID = 1
Station[1]: <mac> leave, AID = 1
Это писали китайцы, но переводится как
join - присоединился
leave - отсоединился
PS: а говорили, что настройки всяких штучек в своей сети в специальные не ставили :)
Выкиньте Askey Computer TAIWAN если не можете справиться с его настройками.
 
Последнее редактирование:
Сверху Снизу