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

[pvvx]

Есть ряд задач где UDP работает на много лучше, не смотря на потери.

Там, где у сервера множество клиентов и он не в состоянии заботиться о каждом и для данных допустимы потери.
Да и скорость отклика что UDP, что TCP всегда одинакова.
Переписывание на UDP - это downgrade. Необходимо многое выкинуть из кодов и это может сделать желающий и самостоятельно
На UDP для передачи в UART вообще ничего не выйдет. Скорость вывода данных UART намного ниже чем передача данных по WiFi и в случае с UDP без специального над-протокола куда будут приниматься данные в устройство если буфер UART заполнен, а сообщить об этом оно не может?

Не случайно Skype и Sip работают с UDP.

Skype и Sip имеют специальный надпротокол над UDP и сами разбираются с потерями пакетов по своему, при передаче файлов симулируя TCP
Так-же существует множество программ создающих удаленный COM порт путем связи по UDP, но они все имеют разные собственные протоколы выше уровнем и кроме потока данных передают туда-сюда управляющий поток. Стандарта на такие протоколы через UDP не существует.
Опубликуйте свой стандарт для этого дела для UDP и если, тогда, его кто поддержит и он приживется - встрою в данную прошивку
Иначе, тем что получится, с иcпользованием UDP, никто, кроме автора нового протокола, воспользоваться не сможет.

 

[Vladimir555]

Pvvx, спасибо за развернутый ответ.
А режим клиента ожидается в этом проекте?
Хотелось бы два ESP соединить с Вашей прошивкой.
Смотрел Ваши тесты.
Поток в 3 Мбит. (с вентилятором) -это сильно для китайской игрушки.
Спасибо.

 

[pvvx]

А режим клиента ожидается в этом проекте?
Хотелось бы два ESP соединить с Вашей прошивкой.

В случае соединения между модулями очень мал буфер. Это влияет на максимальный поток туда-сюда и добиться больших скоростей не выйдет.
Оф. AT прошивка (от 0.23), как клиент, успешно соединяется с имеющейся. Но полного теста не делал. У оф. AT прошивки есть малая беда: - она строит запросы соединения через менее чем через секунду, в случае не успеха, а на некоторых линиях пинг больше (к примеру если связь идет через GSM) и по этой причине не может соединиться. Послав запрос соединения она не дожидается ответа и посылает новый запрос Но это пусть китайцы правят. А то она первым запросом соединяется, но уже посылает второй, забывая о первом и второе соединение открыто быть не может, только через указанный в настройках тайм-аут... когда автоматически закроется первое соединение.
Потыкал как-то Tibbo пакет, как удлинитель COM-порта. Работает. На большие объемы и потоки не проверял.

Поток в 3 Мбит. (с вентилятором) -это сильно для китайской игрушки.

Вентилятор не требуется - после сертификации модулей Espressif исправил ошибки связанные с перегревом чипа от их бездарного подхода к ПО и начиная с SDK 0.9.5 и особенно далее, с 1.0.0 ничего не греется и кушает в пределах 70..100 mA на полной скорости приема/передачи по TCP в 1 мегабайт в секунду. С UART безусловно трансфер меньше - не хватает производительности CPU, а DMA у ESP8266 нет, и перелом где-то на 3 мегабита (полный дуплекс).
----------
Да, последние прошивки на стабильность проверять некогда, а SDK Espressif постоянно набирает новые баги в этом деле и всё время уходит на обход их... С вышедшим патчем к SDK 1.1.0 вообще ничего не сделать - там всё скручено с WDT по новому и накручено ОЧЕНЬ много ненужного... От этого говорить пока о стабильности в новых прошивках (c SDK 1.1.0) нет смысла.

 

[Vladimir555]

Оф. AT прошивка (от 0.23), как клиент пробовал как- то работает часто срывается соединение.
Я имел ввиду два устройства с web настройками TCP2UART.
Как всегда памяти мало...
Тиббо разные начиная от первой оранжевой 5 лет использую и с Wi-Fi модулем.
Поток плохо передают - а греются очень хорошо.

 

[pvvx]

Клиент будет - часть уже написана и проверена. Но не хватает поддержки интерфейсной части, т.к. не продумана его концепция. Слишком много вариантов бывает у "клиента". Надо вводить ещё переменные в Web и т.д...

Поток плохо передают - а греются очень хорошо.

Чипы ESP8266 имеют разные модификации... А так-же модули разные. На ESP-01 часть входов "висят" и впадают в генерацию, а часть включена прямо на GND или VCC и их включение как выход вызывает нагрев чипа. Обращайтесь к китайцам изготовителям модулей. При нормальных условиях и правильной распайке нормального модуля ESP8266 потребление в пределах 100mA на предельном трансфере WiFi. А это всего 330mW.

 

[Vladimir555]

Концепцию интерфейсной части можно подсмотреть у Тиббо. (это не реклама)
На рынке они много лет, жаль аппаратная платформа старая, сильно греется.
Кстати все модули имеют переключение TCP/UDP.

 

[Vladimir555]

Pvvx.
Изучаю Ваш код Web_Base, большое спасибо за русские комментарии.
Трудно разобраться в чужом коде, но я не оставляю надежду
подкорректировать Ваш проект до UDP2UART.
Понимаю что нужно запустить UDP сервер/клиент для порта "12345"
Можно использовать все настройки от TCP, или может все сложнее…
Если не трудно, нужны подсказки.

 

[pvvx]

Если не трудно, нужны подсказки.

Подсказка уже была - куда девать принятый пакет UDP, если буфер UART уже полон? Он-же по другому аналогичному случаю - куда девать и как складывать в UART принятые пакеты UDP, если они идут от сотни источников?
Ответьте на этот простой вопрос - тогда и подсказки...
Упреждающая “подсказка” – если внешний клиент ограничивает передачу по времени, для исключения переполнения выдачи символов UART-том из-за скорости передачи/приема UDP за 1.2 мегабайт в секунду, а у UART для в 300 бод (30 байт в секунду), то модуль с такой программой нельзя включать в глобальную сеть интернет или через роутеры и прочее – он обязательно словит посторонние пакеты или нарвется на "кеширование" в группу пакетов на пути приема-передачи

 

[Vladimir555]

Все верно, всю ответственность за поток берет на верхнее программное обеспечение.
В режиме точка - точка проблем с переполнением нет. В сети кэширование видел - чужих то надо фильтровать.
Сегодня тестировал еще вариант:
После модификации интерпретатора NodeMcu (убрал все лишне, увеличил буферы TX,RX до 1024 байт.) передавал не большой звуковой поток по UDP - битые пакеты есть (как потрескивание).
В режиме TCP все хуже есть дыры на большое время (гарантированная доставка работает, запросы туда - сюда , но уже поздно).
TCP незаменим для веб страниц (все нарисуется рано или поздно), почты, sms ...

 

[pvvx]

TCP незаменим для веб страниц (все нарисуется рано или поздно), почты, sms ...

UART, ...
Для передачи audio всегда применяется надпротокол....
NodeMcu падает при передаче разом более 1 пакета TCP (>1560 байт = MSS) и теряет связь, если клиент правильно завершил передачу (послал конец передачи и ASK). Там SDK 0.9.5 имеющая в этом ошибки.

В режиме точка - точка проблем с переполнением нет.

В UDP не бывает "точка - точка"
Как разобраться, кто будет "точкой" при приеме 100 пакетов в порт UDP от 100 разных источников?
Принимать только с фиксированного указанного заранее адреса ip: port?
А что делать если отосланные пакеты пришли не по порядку? Это норма для интернет сети. (Для адио-драйвера там всё это передается в пакете.)
Вот почти все подсказки, что вам необходимо реализовать эмуляцию TCP с разбором и вложением дополнительной информации в пакеты UDP и получили При оптимальной реализации получите, что отличия для "точка-точка" от TCP будут минимальны - 1 бит в заголовке, указывающий, что пакет UDP, а не TCP + пачка байт для поддержки всего выше описанного (=TCP)
Безусловно известно, что каждый любит сочинять собственный протокол, чтобы он был не совместим с другими (коммерция)

 

[Vladimir555]

Конечно не UART а TCP.
Хотя 3мбита не мало, у меня интернет был 0,64 -0,512-1мб SAT. и ничего.

разом более 1 пакета TCP

- по этому и добавил до 1024 в NodeMcu. В оригинале не работает.
Вот точка - точка в UDP. АР сервер - ST клиент ,без пароля ни кого лишнего.
Тиббо много лет делает переходники TCP/UDP2UART c WEB настройкой.
Но все проблемы с переполнением UDP их не волнуют. Продают как провод UDP-UART.

 

[pvvx]

АР сервер - ST клиент ,без пароля ни кого лишнего.

А мне это не нужно Мне частично нужен сервер для использования прямого канала - простой комп и внешний вход UART у устройства, без проводов. Что почти обеспечивает данная прошивка.
Как пример - на завод приходит настройщик оборудования и втыкает переходник в спец. выход. Идет к месту, где ему легче сесть/лечь и есть сеть, да оборудование не закладывает уши своей работой. Включает ноут и программит оборудование или оставляет для ведения лога с целью вычисления сбоев и т.д..
Но до необходимой стабильности даже это не доделано, пока там куча китай-глюков. По тому меня NodeMcu им прочие детские игрушки (Tibbo и почее) не устраивают. Строить это на Cisco тоже не устраивает - настройщики не Гераклы и не могут таскать с собой тележки с оборудованием

 

[Vladimir555]

Понятно, проект- конфигурация оборудования по WI-FI всем удобно станок с AP сервером.
Втыкать переходник не надо - должен быть в составе станка. Пришел настройщик с планшетом соединился со станком из кабинета начальника цеха, поработал, получил зарплату и ушел.
Насчет подсказок, которые я искал.
я пока не нашел в Вашем проекте как сделать просто провод UDP-UART без всякого контроля пакетов, переполнений и тд.
как я сделал в NodeMcu.

 

[pvvx]

Понятно, проект- конфигурация оборудования по WI-FI всем удобно станок с AP сервером.

Это всего один из вариантов возможных применений.

я пока не нашел в Вашем проекте как сделать просто провод UDP-UART без всякого контроля пакетов, переполнений и тд.
как я сделал в NodeMcu.

https://github.com/pvvx/esp8266web/blob/master/app/user/udp_test_port.c#L282
https://github.com/pvvx/esp8266web/blob/master/app/user/tmp2net.c#L148
Открытие UDP "клиента" обсуждалось ранее, да как сделать запрос ip по имени у dhcp...
По поводу TCP "клиента" пока есть уже рабочий кусок tcpsrv_client_start(). Но ныне занят другим и TCP "клиент" не доделан.
---
Клиент уже работает в новых версиях...

 

[mcmega]

Скажите такой момент:
1. Я подключился к модулю, отправляю команды и они без проблем вылетают из UART ESP8266 (через Web и TCP) на контроллер
2. Контроллер отвечает и шлёт данные подтверждения принятых команд обратно в UART
Как мне принять данные от контроллера?

 

[aloika]

mcmega, в сообщении №99 темы "Разработка библиотеки малого веб-сервера" я выкладывал свой вариант решения. Там есть прием данных и их разбор. Данные принимаются по таймеру, в прерываниях че-то не получилось, видимо, не умею я их готовить. Но все работает. В матричных часах у Andy Korg тоже по таймеру.

 

[FGX]

Добрый день. Пытался передавать через UART2TCP данные с частотой 10 кГц по одному байту через равные промежутки времени на скорости соединения 500 000. Что -то часть данных теряется. Хотя скорость сети высокая, все рядом. В чем причина и можно ли данные передавать потоком при соединении только RX-TX или никак нельзя и нужно смотреть занятость, но если ждать пока он освободится то и данные уже не нужны.

Спойлер: Скрины

а должно быть

 

[pvvx]

Добрый день. Пытался передавать через UART2TCP данные с частотой 10 кГц по одному байту через равные промежутки времени на скорости соединения 500 000. Что -то часть данных теряется. Хотя скорость сети высокая, все рядом. В чем причина и можно ли данные передавать потоком при соединении только RX-TX или никак нельзя и нужно смотреть занятость, но если ждать пока он освободится то и данные уже не нужны.

Спойлер: Скрины

Посмотреть вложение 737
а должно быть Посмотреть вложение 736

Нужно смотреть занятость. Гарантии чистого эфира никогда не бывает. Помехами может быть убит пакет во время передачи и рассчитывать что всё хорошо невозможно. Так-же есть процессы в SDK с запретом прерываний и в этот момент может не хватить fifo UART (тогда она автоматом выставляет RTS).
Можно передавать с подтверждением - передали короткий блок и ждете ответа на него. Длина блока может быть в пару кило (счас назначено TCP_MSS*3 = 1460*3=4380 байта)... Подтверждение приема должен отсылать сторонний модуль, когда примет блок.
На процесс занятости ещё сильно влияет синхронность набора пакета. Примерно так: В одну единицу времени можно передать X пакетов TCP, а от размера данных в них зависит общий трафик. Пакеты имеют n байт, то и трансфер у нас X*n за единицу времени. Т.е. чем больше данных в пакете TCP (ограничение MSS = 1460 байт), тем больше трафик.
В 'Web свалке' есть переменная, ограничивающая время набора пакета.
[HASHTAG]#define[/HASHTAG] MAX_WAIT_TX_BUF 50000ul // 50 ms
Можете попробовать адаптировать её под свою скорость.

 

[FGX]

Нужно смотреть занятость. Гарантии чистого эфира никогда не бывает. Помехами может быть убит пакет во время передачи и рассчитывать что всё хорошо невозможно. Так-же есть процессы в SDK с запретом прерываний и в этот момент может не хватить fifo UART (тогда она автоматом выставляет RTS).
Можно передавать с подтверждением - передали короткий блок и ждете ответа на него. Длина блока может быть в пару кило (счас назначено TCP_MSS*3 = 1460*3=4380 байта)... Подтверждение приема должен отсылать сторонний модуль, когда примет блок.
На процесс занятости ещё сильно влияет синхронность набора пакета. Примерно так: В одну единицу времени можно передать X пакетов TCP, а от размера данных в них зависит общий трафик. Пакеты имеют n байт, то и трансфер у нас X*n за единицу времени. Т.е. чем больше данных в пакете TCP (ограничение MSS = 1460 байт), тем больше трафик.
В 'Web свалке' есть переменная, ограничивающая время набора пакета.
[HASHTAG]#define[/HASHTAG] MAX_WAIT_TX_BUF 50000ul // 50 ms
Можете попробовать адаптировать её под свою скорость.

Спасибо за ответ. Сделал проверку RTS вывода ESP и выходной буфер на 1024 значения, стало получше, но иногда данные все-равно теряются, на RTS выводе действительно раз в пару секунд появляется сигнал занятости, поэтому без его контроля не обойтись. Данные пробовал собирать в пакеты по 512 байт и слать в ESP и пробовал отправлять сразу по байту, разницы нет, ESP как я понял все равно у себя их собирает пока не насобирает 1460 байтов или не выйдет задержка в 50 мсекунд. А теряются данные видимо потому что ESP занят бывает больше чем 0,2 секунды и моего буфера в 1024 значения не хватает. Такие пироги, просто прямой замены не получилось обычному ком порту, туда можно вообще без буфера все слать и ничего не теряется. Тем не менее уже норм работать можно, кривая красивая.

Спойлер: Скрин

 

[pvvx]

но иногда данные все-равно теряются, на RTS выводе действительно раз в пару секунд появляется сигнал занятости, поэтому без его контроля не обойтись

Это видимо связано с процессами в SDK.
Попробуйте поменять скорость UART (увеличить в несколько раз) и лить данные пакетами с промежуточными паузами (лучше все-же с проверкой RTS перед передачей пакета). Это, возможно, сможет помочь при отсутствии у внешнего устройства аппаратного CTS и условии чистой (близкой) связи по WiFi.

Аппаратный сигнал RTS в прошивке, счас, выставляется при наличии свободных 16 байт в fifo UART.

просто прямой замены не получилось обычному ком порту, туда можно вообще без буфера все слать и ничего не теряется.

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