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

[aneox]

@pvvx
Я не особо силен в анализе тсп пакетов, может вы глянете? У меня передатчик айфон, есп в роли ап. Я перевел карточку на ноуте в режиме монитора и сдампил немного трафика. Заметил там что пакеты длинной 79, это ответы девайса, т.е 192.168.4.1, а где посылка с телефона я только догадываюсь, но не увидел задержек здесь. Так же пробовал в программе на телефоне вырубить подготовку пакета, чтоб он слал одно и тоже, без подготовки контролек и прочего, померил там же таймером, между получением DONE#номер пакета с девайса и отправкой, 2-3мс таймер выдал. Помогите разобраться плиз. Точная длина данных в пакете 6160 байт.

дамп tr-01.cap

Но и это пол беды, это влияет на скорость только. А вот порт закрывается ска при маленьких пакетах 6кб, это беда.

 

[pvvx]

@pvvx
Я не особо силен в анализе тсп пакетов, может вы глянете? У меня передатчик айфон, есп в роли ап. Я перевел карточку на ноуте в режиме монитора и сдампил немного трафика. Заметил там что пакеты длинной 79, это ответы девайса, т.е 192.168.4.1, а где посылка с телефона я только догадываюсь, но не увидел задержек здесь. Так же пробовал в программе на телефоне вырубить подготовку пакета, чтоб он слал одно и тоже, без подготовки контролек и прочего, померил там же таймером, между получением DONE#номер пакета с девайса и отправкой, 2-3мс таймер выдал. Помогите разобраться плиз. Точная длина данных в пакете 6160 байт.

дамп tr-01.cap

Ну из вашего дампа, первые попавшиеся:

Конец передачи блока: 78 18:12:19.229408 192.168.4.3 192.168.4.1 TELNET 392 Telnet Data ... Len: 320
Пришел ответ: 84 18:12:19.229387 192.168.4.1 192.168.4.3 TELNET 79 Telnet Data ... Data: DONE:73
Следующая передача нового блока: 88 18:12:19.229410 192.168.4.3 192.168.4.1 TELNET 1532 TelnetData ... Len: 1460
-------
Конец передачи блока: 148 18:12:19.272418 192.168.4.3 192.168.4.1 TELNET 392 Telnet Data ... Len: 320
Пришел ответ: 154 18:12:19.279053 192.168.4.1 192.168.4.3 TELNET 79 Telnet Data ... DONE:79
Следующая передача нового блока:158 18:12:19.284703 192.168.4.3 192.168.4.1 TELNET 1532 Telnet Data ... Len: 1460

Т.е. ответ от 192.168.4.1 приходит через 0.000021 сек и второй раз через 0.006635 сек от времени отсылки к 192.168.4.1 последнего куска на 320 байт от передачи блока.
После приема ответа ваш софт тупит до передачи нового блока: 0.000023 и 0.00565 сек

Ещё:
Конец передачи блока: 273 18:12:19.391715 192.168.4.3 192.168.4.1 TELNET 392 Telnet Data ... Len: 320
Блок передается и через 0.005099 сек:
Пришел ответ: 277 18:12:19.396814 192.168.4.1 192.168.4.3 TELNET 79 Telnet Data ... DONE:84
Ответ принят и через 0.006673 сек:
Следующая передача нового блока: 281 18:12:19.403487 192.168.4.3 192.168.4.1 TELNET 1532 TelnetData ... Len: 1460
Т.е. пауза между блоками тут равна 0.005099+0.006673 сек.

Итого картина примерно такая:
не менее 320*10/4000000=0.0008 сек в TX ESP8266 передаются последние 320 байт блока и кто-то должен ответить - через сколько - неизвестно. Но отвечает 7 байт. Далее эти байты передаются с ESP8266 и принимаются на компе. Это итерация занимает почему-от 0.000021 до 0.006635 сек (из примеров лога).
Потом на компе идет обработка ответа и через от 0.000023 до 0.006673 сек он начинает пересылать новый блок...

Но и это пол беды, это влияет на скорость только. А вот порт закрывается ска при маленьких пакетах 6кб, это беда.

А может ESP перегревается? Китайское чудо не рассчитано на такие скорости работы на постоянку. Пробуйте снижать уровень передачи.
В логе много [TCP Retransmission] и [TCP Dup ACK]. Наверно теряются пакеты...
ЗЫЖ на сегодня лавочка бесплатных односторонних ответов закрыта Еси не ответите на мой вопрос: На ADuC7061 SPI настроен на вызов прерывания после передачи 3-х байт. На шине SPI висит DAC8750. Ему надо передавать 24 бита и читать тоже 24 бита. После передачи 3-х байт у него срабатывает SS как строб для DAC8750. Что передача прошла узнаю по аппаратному прерыванию передачи 3-х байт по нему делаю и считывание принятых по SPI байт. Произвожу загрузкой 3-х байт в регистр передачи SPI и жду. Иногда, раз в час или более, при чтении статуса с DAC8750 (несколько раз в секунду) от него приходит голая шина 0x??FFFF или 0x??00FF. Первый байт (??) там не нужен и откидывается. Дык что не так ему, если скорость SPI 1 Mbit (и более и менее - результат тот-же). Анализатором словить не удалось. Слишком редко этот сбой, но это серьезно, т.к. в статусе есть бит перегрева и прочее... Кривая микросхема и не может отличить уровень (ADuC 2.5В, ref DAC8750 на 3.3В)? (повторяемость на нескольких платах)

 

[aneox]

Потом на компе идет обработка ответа и через от 0.000023 до 0.006673 сек он начинает пересылать новый блок...

Тоже заметил что задержка на компе не всегда есть. Но в анализаторе по уарту задержка самая мелкая 8-9, самая большая 14-15. Т.е если отравили новый за 0.000023, то висит в есп пауза?

А может ESP перегревается? Китайское чудо не рассчитано на такие скорости работы на постоянку. Пробуйте снижать уровень передачи.
В логе много [TCP Retransmission] и [TCP Dup ACK]. Наверно теряются пакеты...

tx power 40 стоит, вообще не греется. И причем если толкать с компа 6кб пакет, не могу передать больше 20мб, а 28кб пакетом удается пропихнуть 200+мб. Т.е явно чтото в прошивке, а не аппаратно косяк.

 

[pvvx]

tx power 40 стоит, вообще не греется. И причем если толкать с компа 6кб пакет, не могу передать больше 20мб, а 28кб пакетом удается пропихнуть 200+мб. Т.е явно чтото в прошивке, а не аппаратно косяк.

Такое уже было на старых версиях китай-SDK. При интенсивной передаче на ESP происходили сбои (ранее это проявлялось на передаче к записи во flash web-диска). Потом пропадало. Потом опять вылезало. Иногда лечилось снижением частоты проца на время такой суматохи при отдаче управления в китай-часть обработки WiFi (это давало задержки и прошивка с непрерывным приемом удавалась). По этому жду новый SDK и только после этого буду думать, если повторится. У них патчи выходят с кометом от их программера - "перетранслировал и стало работать". Ведь в их исходниках все варнинги компилятора и прочее отключено... А ошибок, включая алгоритмические там тысячи. Это ещё одна из причин по чему не могут дать исходники - им страшно, что мир увидит там А мне не страшно - я не проф. программист.

И у вас по логу не оптимизирована передача. Оптимально на каждый пакет TCP передавать подтверждение по UART. Тогда не будет задержек с лишними пустыми ACK пакетами... Примерно так: передали на ESP 2 блока по 1460 байт, когда они принялись, ближе к концу, к примеру при приеме 2900 символа блока по UART передавать ответ в пару байт... Тут надо смотреть по времени - на каком приемном сиволе от блока передавать ответ оптимальнее... Может и на начале второй половины - после 1461-го байта... А его прием будет означать передачу следующего блока. Но разрывы в приеме всё равно будут - это что-то китайское там ворочается и всегда делает дырки. Во время них ничего не передать или принять.

 

[aneox]

@pvvx
Понял вас, спасибо, попробую когда удастся уйти от паузы между запрос-новый пакет. Сейчас стремился к большему пакету чтобы получилось меньше запросов, соответсвенно пауз. С пакетом 6кб фактическая скорость на выходе 210кбс у меня, а с 28кб пакетом 320кб/с, потому как запросы тупо реже идут, ну и паузы между ними реже. В идеале думаю с 4мбитами уарта можно попробовать к 400кбс приблизиться попробовать. Дождусь тогда новое сдк и буду опять пробовать.

 

[pvvx]

Дождусь тогда новое сдк и буду опять пробовать.

С каждым новым SDK всё больше там ненужного - они же там в WiFi анализируют всякие другие протоколы и всё становится ещё тормознее. Китайцы пишут же к каждой новой SDK "оптимаза" и после этого всё хуже и хуже А разделить хоть на закрытые куски библитек по примитивам не могут, чтобы можно было собрать только то, что надо для данной прошивки, а не впихивать туда сотни килобайт лишнего, никогда не отрабатывающего кода.

 

[aneox]

@pvvx ну кстати да) на 054а скорость у меня была 335, а сейчас 059, 317кбс, хотя мож с паузами перемены повлияли

 

[pvvx]

ну кстати да) на 054а скорость у меня была 335, а сейчас 059, 317кбс, хотя мож с паузами перемены повлияли

Вот с flow-control UART на 3 mbit/s (больше не тянет FT2232C и это уже с паузами RTS/CTS на ней), включение и выключение передачи вручную и между посылками в UART есть паузы и не стыковка по размерам пакетов (софт кое как написан):

80 секунд работы. Итог - BytesReceived: 19505152, BytesSent: 20234240. = 252928 байт в секунду в одну сторону и 243814.4 в другую (криво так-как вручную - кнопки пуск/стоп раздельные и прием передача программы блоками драйверам). Общий дуплекс 496742.4 байт в сек.
Вот ESP при этом часто глючит на описанной ранее беде с каким-то буфером - умирают WiFi передачи. Решается только сбросом.

 

[aneox]

@pvvx ну я седня по кругу гонял, бывало 15минут работало на скорости 317кб/с, мининум 10 минут пашет))

 

[pvvx]

ну я седня по кругу гонял, бывало 15минут работало на скорости 317кб/с, мининум 10 минут пашет))

У вас не полная загрузка прием-ответ. Загрузите - накроется. На всех типах модулях это у меня. Как-бы для вас это типа в одну сторону 6 мегабит, чтобы был равный общий трафик.

 

[boomer]

Всем привет! Подскажите в какую сторону копать. Залил прошивку tcp2uart переходника, на страницу настройки сервера захожу, все работает, но не могу найти инфу как теперь связать программно esp8266 с микроконтроллером по uart.

 

[Andy Korg]

...как теперь связать программно esp8266 с микроконтроллером по uart.

Открываете порт TCP/IP указанный на странице настройки какой нибудь программой, telnet например, и шлете туда байты. Эти байты появляются на порту uart esp. Соответственно все что попадает на uart порт esp транслируется в telnet.

 

[boomer]

... Соответственно все что попадает на uart порт esp транслируется в telnet.

Спасибо, теперь разобрался

 

[aneox]

@pvvx

Хочу поделиться наблюдениями. Вообщем вроде как добился я устойчивой работы своего протокола. Передал больше 3 гигабайт успешно, дальше не стал ждать, буду пробовать внедрять уже в устройство и дальше тестить в реальных условиях, жара и прочие невзгоды. По сути мне нужно то, чтоб пользователь мог прошить девайс файлом 20мб, просто хочется стабильности и скорости.

Как я выше писал, есп время от времени закрывает порт при передаче. Вылечил я эту проблему, таймером со стороны передающего, который переоткрывает порт в случае задержки, помогло. Частота этого глюка напрямую зависит от чего то со стороны тсп. Деталей не скажу, но есть два примера.

Если я подключен с планшета напрямую к есп, то глюк замечен всего лишь трижды во время передачи 3гб. Пакеты приходят плотным, хорошим потоком в уарт.

Если я подключен через домашнюю сеть, через два ната) есть роутер, подключенный в режиме клиента к есп, и к ван порту мультиван роутера, дальше лан и точка доступа wifi, и уже передатчик - планшет. При таком подключении, отсылаемый пакет 40кб(да, я с 28кб поднял до 40), приходит в уарт кусками, мелкими, но приходит. Так вот, порт приходится дергать раз, а то и два, КАЖДЫЕ 20мб. Удобно было отлаживать протокол в таком подключении, с кучей проблем)

Также переписал свою отправку с подготовкой второго пакета в другом потоке и удалось получить задержку меж пакетами 4-4.5мс, меньше пока никак) с 4.5мс задержкой и пакетом 40кб получил рекордную для себя фактическую скорость на выходе, 380кб/с. Это на скорости уарта 4.0мбит

Вот только что решил попробовать поднять ее, скорость уарта, вроде как стм может до 4.5. Веб морда подобрала ближайшую 4444444, работает) 415-420кб/с получаю, уже 200мб передалось, стабильно) Вот не знаю, оставлять или нет. Со стороны есп вроде 160мгц/4.444444 почти ровно 36.0000036... А вот стм 72мгц/4.444444 = 16,20000162.. Оставлю на ночь погонять тогда, других методов повысить скорость всеравно не остается, хотя можно сделать проверку контрольки позже, которая у меня занимает 2.2мс ...

Спасибо вам за прошивку!

 

[oleg_777]

@pvvx
Как я выше писал, есп время от времени закрывает порт при передаче. Вылечил я эту проблему, таймером со стороны передающего, который переоткрывает порт в случае задержки, помогло. Частота этого глюка напрямую зависит от чего то со стороны тсп.

Тоже иногда перестает отвечать. Вылечил точно также. По логам заметил что в эти периоды происходит, следующее:

1) пакеты отправлены в esp, а от него тишина
2) пакеты отправлены в esp, и через несколько пакетов его как бы прорывает и он отправляет все предыдущие сразу

Между пакетами таймаут 200 мс.

Я подключен через роутер.
Задержка 4 мс.
Скорость 115200 бит/сек.

И тоже спасибо вам за прошивку!

 

[pvvx]

По логам заметил что в эти периоды происходит, следующее:

1) пакеты отправлены в esp, а от него тишина
2) пакеты отправлены в esp, и через несколько пакетов его как бы прорывает и он отправляет все предыдущие сразу

Между пакетами таймаут 200 мс.

На этой "задержке" где-то в потрохах и происходит "no buf for action frame" при 3 мегабита в обе стороны.

 

[Gena_G]

Добрый день. Подскажите пожалуйста.
ESP (TCP client) - > ESP (TCP server) - > UART - > PC. Все прекрасно работает, но если данные не приходят на сервер дольше чем 25 секунд то перегружается ESP клиент. Данные у меня идут раз в минуту, и это отсчет времени. Размер пакета около 10 байт. Timeout стоят нулевые

 

[pvvx]

Добрый день. Подскажите пожалуйста.
ESP (TCP client) - > ESP (TCP server) - > UART - > PC. Все прекрасно работает, но если данные не приходят на сервер дольше чем 25 секунд то перегружается ESP клиент. Данные у меня идут раз в минуту, и это отсчет времени. Размер пакета около 10 байт. Timeout стоят нулевые

Не понятно что такое "перегружается ESP клиент"?

 

[Gena_G]

Не понятно что такое "перегружается ESP клиент"?

В esp8266 залита программа из среды Arduino . Программа подключается к серверу TCP , опрашивает инфракрасные датчики . При прохождении мимо датчика идет отсечка времени и считывается номер датчика. Так вот если данные не идут 25 секунд то программа перегружается (а команду дает ESP сервер) если передавать данные допустим раз в 10 сек то все работает нормально . Я делал типа такого сервера чисто методом Arduino , но соединение было не стабильно. Но когда было не рвалось.

 

[pvvx]

В esp8266 залита программа из среды Arduino . Программа подключается к серверу TCP , опрашивает инфракрасные датчики . При прохождении мимо датчика идет отсечка времени и считывается номер датчика. Так вот если данные не идут 25 секунд то программа перегружается (а команду дает ESP сервер) если передавать данные допустим раз в 10 сек то все работает нормально . Я делал типа такого сервера чисто методом Arduino , но соединение было не стабильно. Но когда было не рвалось.

Так и не ясно - кто перегружается? Соединение, порт TCP2UART, если выставлены времена 0,0 не закрывается, если не пришла команда закрытия с другой стороны. При сервере TCP2UART, повторное обращение на открытие порта TCP2UART вызывает закрытие прошлого соединения, если выставлена галочка повторного открытия. Других закрытий соединений нет, если связь по WiFi не потеряна.
Arduino в большинстве случаев не умеет держать постоянные соединения. Обращайтесь к портировщикам Ардуны на ESP.