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

[Артемий]

Почти ни как. Расчет идет на соединение в качестве удлинителя. На одно модуле ставите AP, а на другом ST и указываете ip адрес (и порт TCP2UART) первого модуля...
Передать пару байт через web можно в запросе, через переменные, как указано в http://sesp8266/sample.htm.
Прямо в регистры UARTx :
http://aesp8266/web.cgi?sys_ram0x60000f00=0x48&sys_ram0x60000f00=0x69&sys_ram0x60000f00=0x21 передает в UART1(debug port): 'Hi!'
http://aesp8266/web.cgi?sys_ram0x60000000=0x48&sys_ram0x60000000=0x69&sys_ram0x60000000=0x21 передает 'Hi!' в UART0 TX.

Так подождите , почему "почти никак" ? Получается "еще как"!
Мне надо просто прикрутить веб морду к девайсу на стм32, и управлять настройками через веб. И получать параметры из устройства . Вот и вся задача.. Максимум десяток байт нужно слать и получать.

 

[pvvx]

Так подождите , почему "почти никак" ? Получается "еще как"!
Мне надо просто прикрутить веб морду к девайсу на стм32, и управлять настройками через веб. И получать параметры из устройства . Вот и вся задача.. Максимум десяток байт нужно слать и получать.

Для этого каждый раз требуется спец.протокол, а тут TCP2UART, а не WEB-HTTP-UART. На Web нет стандарта для пересылки данных RS-232.
Исходники даны, но как прикрутить многопользовательский Web-HTTP к однопользовательскому UART пока никто не смог решить, кроме как Arduino-вцы и прочие, которым всё равно, главное написать блог о мигании светодиодом

 

[dosikus]

pvvx, видимо небольшой ликбез все-таки нужен.
Как пользоваться Save Test Wav?
У меня просто сохраняет файл с расширением wav c содержимым ~test_adc~ .

 

[pvvx]

pvvx, видимо небольшой ликбез все-таки нужен.
Как пользоваться Save Test Wav?
У меня просто сохраняет файл с расширением wav c содержимым ~test_adc~ .

Значит при сборке диска была не задана опция трансляции *.wav:

(возможно я пропустил и недоглядел при сборке...)
При внешних опциях в make_webfs.bat: PVFS2.exe -h "*.htm, *.html, *.cgi, *.xml, *.bin, *.txt, *.wav" -z "*.inc, snmp.bib" .\WEBFiles .\webbin WEBFiles.bin

Динамические файлы - это для которых ставиться атрибут в WEBFiles.bin, указывающий что они должны "парситься" при передаче, если в них программой PVFS2.exe будут найдены переменные заключенные в "~". В остальных файлах поиск динамических переменных не производится и они могут быть сжаты GZIP при помещении в WEBFiles.bin.

Тестовый wav - это просто генерация маленького wave файла, как простейший пример для 'демки' работы с ADC (для тех кто копает в исходниках).

 

[Vasay]

Здравствуйте!

pvvx, спасибо за прошивку!

У меня вопрос: при передачи данный (> 5 kБ ) в UART на скорости 3076923 бод каждый раз после определенного количества данных ( примерно 4.5 kБ) возникает пауза примерно 188мс. пробовал на других скоростях эффект тот же. В Wireshark не чего плохого не увидел.
ESP8266 соединен с компьютером на котором стоит Tibbo. с Tibbo использовал другой китайский wifi модуль таких задержек не было.

Я так понимаю ESP чем-то занят. или чего то ждет.

Подскажите с чем это может быть связано и можно ли эту задержку убрать (ведь дальше при передачи данных большего размера такой задержки больше не возникает)?

прикреплен файл (передаю в UART 16 kБ):
желтый луч RxD ESP
синий луч RTS ESP

С прошивкой AT v0.25 такого нет. Но там почему то не ставится скорость больше чем 115200*13 (~1500000)

 

[Sergey476]

добрый день,
подключил TCP2UART к GPS приёмнику по ком порту на скорости 4800. данныепринимаю через wifi программой nmearouter. Программа раз в несколько секунд выдаёт ощибку осуствие CR,LF. при этом довольно стабильно и в одноми том же месте.Пробывалпрошивки от 0.39 до 0.44 -результат такой-же.Хотел протестировать стандартную прошивку, но не понял как задавать at через Tcp , ведь uart будет занят под передачу данных.

 

[pvvx]

возникает пауза примерно 188мс.

Существует завязка с режимом WiFi-sleep. В старых прошивках по умолчанию ставился режим NONE, в новых MODEM. Это может влиять на возникновение пауз. Попробуйте поставить NONE.

С прошивкой AT v0.25 такого нет. Но там почему то не ставится скорость больше чем 115200*13 (~1500000)

Возможно что-то связанное с закрытой частью китайского SDK. С последними новыми версиями SDK я полного теста не делал. Ранее были какие-то провалы, но реже.

 

[pvvx]

добрый день,
подключил TCP2UART к GPS приёмнику по ком порту на скорости 4800. данныепринимаю через wifi программой nmearouter. Программа раз в несколько секунд выдаёт ощибку осуствие CR,LF. при этом довольно стабильно и в одноми том же месте.Пробывалпрошивки от 0.39 до 0.44 -результат такой-же.

Скорее всего nmearouter ожидает что ему будут приходить пакеты с полной строкой от GPS, заканчивающиеся CR, LF. А при приемо-передаче данных UART - TCP используется ожидание всего 50 ms до донабора пакета передачи. При этом, если за это время (50ms) данные не набрались, то произойдет отсылка того что есть. В итоге поток может быть нарезан как угодно и в пакетах могут попадать неполные строки GPS (начало строки в текущем пакете, а конец в следующем). Т.к. nmearouter работает и с UDP, то он явно ведет неполноценный потоковый прием, а работает на пакетном принципе. Т.е. он не совместим с стандартными поточными приемо-передатчиками, коим и является данный TCP2UART.
Возьмите исходники и скорректируйте задержку времени отсылки неполного буфера в tcp2uart.h под вашу задачу:
[HASHTAG]#define[/HASHTAG] MAX_WAIT_TX_BUF 50000ul // 50 ms
Это может помочь, но не гарантирует совместимости с недоделанным TCP приемником у nmearouter.

 

[Sergey476]

Возьмите исходники и скорректируйте задержку времени отсылки неполного буфера в tcp2uart.h под вашу задачу:
[HASHTAG]#define[/HASHTAG] MAX_WAIT_TX_BUF 50000ul // 50 ms
Это может помочь, но не гарантирует совместимости с недоделанным TCP приемником у nmearouter.

Спасибо за идею.Но к сожалению проблема наблюдается не только с nmearouter, но с програмой для android GPSbridge. Она через некоторое время блокируется из ошибки в данных.Самое интересное, что nmearouter выдает ошибку всегда только на первую строчку в пачке GPS данных .

 

[Vasay]

Изменение Sleep Mode результата не изменил. (у меня модуль настроен на SoftAP)

Если посылаю меньше или равно 4638 байт - все хорошо
при посылки 4640 байт - отсылается примерно 4 360 байт затем возникает пауза примерно 180-200 мс потом остаток примерно 280 байт

 

[pvvx]

Изменение Sleep Mode результата не изменил. (у меня модуль настроен на SoftAP)

Если посылаю меньше или равно 4638 байт - все хорошо
при посылки 4640 байт - отсылается примерно 4 360 байт затем возникает пауза примерно 180-200 мс потом остаток примерно 280 байт

3*MSS = 3*1460 = 4380. Т.е. три полных TCP пакета и 280 - это не полный 4-ый пакет. Lwip "съедает" 2*MSS - это буфер у него отсылку сразу 2-х пакетов. 3-й кусок (1460+xx) остается в буфере TCP2UART. Далее приходят ваши 280 байт, за это время (или около) отсылается третий пакет TCP, и на этих ~300 байтах система встает на ожидание выше описанных 50ms, в надежде добить пакет. Задержка на отправку более 50ms, после приема последнего байта вашего блока в 4,5 кило делает уже LwIP и приемная сторона. Существует пару типов приема и оптимизации скорости TCP стеков - один метод: Передатчик отправляет сразу 2 пакета TCP и ждет подтверждения приема от приемника (ACK) (Google Chrom) или простой метод - подтверждается прием каждого пакета (MS Explorer). Буфер у Lwip мал и пока он не подтвердит передачу своего стека (2*MSS) он не может предавать новые данные... Т.ч. в данной задержке может быть завязана и приемная сторона, т.к. кол-во пакетов не кратное ...

 

[pvvx]

Спасибо за идею.Но к сожалению проблема наблюдается не только с nmearouter, но с програмой для android GPSbridge. Она через некоторое время блокируется из ошибки в данных. Самое интересное, что nmearouter выдает ошибку всегда только на первую строчку в пачке GPS данных .

Но это всё GPSbridge, а они обычно отсылают пакеты с полными строками, заканчивающимися CR/LF для совместимости с UDP передачами. Скорость у вас низкая, TCP2UART должен передавать и редко идущие байты (нажатия клавиш) и непрерывный поток на пределе TCP (для этого желательно собирать и отсылать по возможности полные пакеты), по тому и стоит задержка в 50ms... За 50ms на 4800 передается всего 2,5 байта.

 

[Tomahawk]

Извиняюсь, но на 4800 работать при текущих возможных скоростях это извращение какое-то Я бы другие варианты поискал, если 4800 это предельная скорость работы из-за помех или чего-то ещё.

 

[pvvx]

Извиняюсь, но на 4800 работать при текущих возможных скоростях это извращение какое-то Я бы другие варианты поискал, если 4800 это предельная скорость работы из-за помех или чего-то ещё.

Ну наверно там дистанция от GPS до ESP8266 пол километра...

 

[Vasay]

Lwip "съедает" 2*MSS - это буфер у него отсылку сразу 2-х пакетов. 3-й кусок (1460+xx) остается в буфере TCP2UART. Далее приходят ваши 280 байт, за это время (или около) отсылается третий пакет TCP, и на этих ~300 байтах система встает на ожидание выше описанных 50ms, в надежде добить пакет.

Не совсем так.
если смотреть направление UART - ESP8266-WiFi

Первый пакет приходит (отправляется ESP8266) не 1460 а 125 байт после чего, я так понимаю, верх перед отправкой подтверждения ждет примерно 200мс (ждет пока пакет в 1460 байт наполнится).

Спойлер: qqq

Time --------------- Info
8.596119000 ------ 4097→20000 [PSH, ACK] Seq=1 Ack=1007 Win=5363 Len=124
8.795567000 ------ 20000→4097 [ACK] Seq=1007 Ack=125 Win=63955 Len=0

Тоже самое происходит в конце передачи, когда остаток отправляемых данных не 1460 байт.

Получается в начале передачи 200мс и в конце 200мс, 400мс уходит.

Вопросы:
1) Почему размер первого пакета 125 байт (иногда 124 байта), а не пакет в 1460 байт? (передача в ESP идет непрерывно)
2) Если выставлен флаг PSH почему идет ожидание 200мс? ( но это скорее вопрос к верху)
3) Как можно этого избежать ?

 

[pvvx]

Не совсем так.
если смотреть направление UART - ESP8266-WiFi

Первый пакет приходит (отправляется ESP8266) не 1460 а 125 байт после чего, я так понимаю, верх перед отправкой подтверждения ждет примерно 200мс (ждет пока пакет в 1460 байт наполнится).

Спойлер: qqq

Time --------------- Info
8.596119000 ------ 4097→20000 [PSH, ACK] Seq=1 Ack=1007 Win=5363 Len=124
8.795567000 ------ 20000→4097 [ACK] Seq=1007 Ack=125 Win=63955 Len=0

Тоже самое происходит в конце передачи, когда остаток отправляемых данных не 1460 байт.

Получается в начале передачи 200мс и в конце 200мс, 400мс уходит.

Вопросы:
1) Почему размер первого пакета 125 байт (иногда 124 байта), а не пакет в 1460 байт? (передача в ESP идет непрерывно)
2) Если выставлен флаг PSH почему идет ожидание 200мс? ( но это скорее вопрос к верху)
3) Как можно этого избежать ?

Да, первый блок, после паузы приема по UART-RX более 50 ms отсылается сразу, не дожидаясь ничего. Требуется для исключения задержки в запросо-ответных системах и типа передачи скана "кнопок".
Но ожиданий более пары десятков ms при работе UART на 3Mb/s я не наблюдаю.
Вот пример конца первого блока и начала отсылки второго:

Время указано в промежутках до следующего. Вот перед последними блоками 274-275 и видим паузу ожидания "добора пакета" на 50ms.
Все остальные паузы рождены временем подтверждения TCP пакетов приемником.
Пример начала передачи в RX-UART на 3Mb/s блока на 64 килобайта (с начальным открытием соединения):

Пакет N60 - подтверждения от стека TCP на компе сделал паузу в 208 ms, не давая модулю передавать дальше. Причина - он ожидал другого метода оптимизации передачи.

На вопрос 3), если он о начальном коротком пакете, то поставить сравнение, если время от последней передачи значительно более 50ms, то не передавать пока буфер не заполниться до размера свободного объема у LwIP. Но надо ещё как-то сравнивать идет ли дальнейшая передача...
Что-то типа: if((time_us - old_time_send_tx) > ((3*MAX_WAIT_TX_BUF)/2)) old_time_send_tx = time_us; в 90 строку tcp2uart, что тоже не совсем корректно... т.е. для ускоренной передачи блоков фиксированной длины на фиксированной скорости UART, да с учетом метода приемного стека TCP и ограничений LwIP в модуле требуется написание специализированного, адаптирующегося (меняющего размеры пакетов под скорость UART и соединения TCP) и разбирающего массу вариантов алгоритмов стека TCP приемной стороны... а такое лень делать.

 

[Vasay]

Все задержки из-за стека TCP на компе.

Время между посылками модулю ESP8266 (по линии UART) у меня больше чем 50ms. Вот и получается что первый пакет данных модуль отсылает данные не набрав буфер (почему то получилось 124-125 байт). И как вы сказали из-за какой-то оптимизации (я так понял ждет пока заполнится буфер стека TCP на компе) и происходит задержка. Комп не отсылает подтверждения в течении 200ms.

Не понятно почему стек TCP на компе чего то ждет если в TCP пакете выставлен флаг PSH

Но ожиданий более пары десятков ms при работе UART на 3Mb/s я не наблюдаю.

На линии первая задержка видна когда заполняются буфер LwIP и UART. вторую можно увидеть только снифером. Задержка после первого и последнего пакета из за стека TCP на компе.( Ваша вторая картинка номер пакета 59 (первый пакет при передачи посылки с паузой более 50ms).)

Получается что если мне надо послать допустим 3500байт (рис. 122):
124 байт |задержка 200ms| - 1460 байт |маленькая задержка|- 1460 байт |маленькая задержка|- 462байт |задержка 200ms|


при скорости 3000000 бит/с отправка этого буфера по линии UART займет 13ms (10*4000/3000000)
и эта огромная задержка более чем 400мс. (в итоге скорость 80 000 бит/с).


Вопрос:
1) Использовал Tibbo настроек не нашел. Накидал свою программу работы с сокетами. Убрать задержку (оптимизацию) не получилось. (интересно что перед отправкой ACK последнего пакета иногда ждет 200ms а иногда нет. )
Не подскажите как эту оптимизацию выключить?

2)Почему именно 124 -125 байт первая посылка после паузы на линии UART-RX более 50 ms?
не логичнее было бы дождаться например разрыва посылки? (задержка между байтами на линии RX больше чем определенное значение например 10/rate или 5/rate (задержку привязать к скорости)).

 

[pvvx]

Не понятно почему стек TCP на компе чего то ждет если в TCP пакете выставлен флаг PSH

Алгоритм TCP стека такой. Он разнится, если использовать разные либы в Windows.

1) Использовал Tibbo настроек не нашел. Накидал свою программу работы с сокетами. Убрать задержку (оптимизацию) не получилось. (интересно что перед отправкой ACK последнего пакета иногда ждет 200ms а иногда нет. )
Не подскажите как эту оптимизацию выключить?

Передавать всегда 2-мя пакетами. "Технология TCP с отложенным подтверждением", упоминается в https://ru.wikipedia.org/wiki/Алгоритм_Нейгла

2)Почему именно 124 -125 байт первая посылка после паузы на линии UART-RX более 50 ms?
не логичнее было бы дождаться например разрыва посылки? (задержка между байтами на линии RX больше чем определенное значение например 10/rate или 5/rate (задержку привязать к скорости)).

Логичнее дождаться, но необходимо несколько таймеров и более сложный код. Со скоростью UART требуется связывать и не только то, что описываете, что ведет к сильному усложнению и увеличению кода. Но CPU ESP8266 и его оборудование уже не справляется со скоростью UART 3Mb/s с обработкой TCP. Это практически предельная скорость обслуживания UART по прерываниям с работающим TCP для получения непрерывного потока по TX и RX с уже отключенными всякими командами "memw" (синхронизации с шиной) через опции транслятора (это не используют все другие прошивки, кроме данной и у них ещё хуже). Проблема заключается в медленной шине (26MHz) к UART и другим регистрам периферии. Большую часть времени CPU занимает ожидание чтения значений по шине от UART (при 160MHz CPU чтение регистра UART = 6 или 7 тактов). DMA для UART не дано. Памяти у чипа мало - малы буферы, на каждый принятый-отосланный байт уходит много кода, а работа TCP (обработка WiFi и работа LwIP у китайцев не оптимизирована под данную структуру CPU). Полудуплексный TCP трансфер модуля на частоте CPU в 160 MHz составляет в пике к 1,5 Мегабайт в секунду, если нет активной работы с регистрами периферии и всё максимально оптимизировано (кроме закрытого китай-кода, т.к. исходников к ним нет). Всякие Arduino уже не могут дать и 200 кило в секунду, а при работе с UART - вообще смешно...
В совокупности и выходит вывод - делайте специализированную под вашу задачу систему. Она будет отличаться от текущей системы TCP2UART оптимизированной на нечто средние...

 

[Sergey476]

Извиняюсь, но на 4800 работать при текущих возможных скоростях это извращение какое-то

Дело в том, что скорость определяется необходимым объемом передаваемой информации,а не достижением в скорости UARTa. Очень много датчиков (топлива, скорости, давления, радаров, ускорения и т.д.) работают по стандарту NMEA0183 в котором скорость по умолчанию 4800. Этой скорости им за глаза достаточно. Передалывать эти датчики на скорость 115к или 3м никто не будет т.к. не понимает зачем.
С низкими скоростями действительно сейчас большая проблема. 1 байт на скорости 4800 выходит из Com порта за 2мс. Т.е. при прямом подключение датчика к компьютеру компьютер начнёт получать данные с задержкой 2 мс. При подключении через TCP2UART задержка первого байта составит 2мс*125=250 мс. т.е. задержка становиться больше чем в 100 раз. Это очень грустно ,что используя скорости в wifi 802.11n мы не можем передать самый медленный интерфейс.

Я бы другие варианты поискал, если 4800 это предельная скорость работы из-за помех или чего-то ещё.

Предложите... Задача следующая:Есть GPS приёмник, который выдаёт данные в NMEA. Есть Спидометр, компас, компьютер, планшет которые должны одновременно эти данные принимать и обрабатывать.растояние не более 5 метров.

 

[pvvx]

Предложите... Задача следующая:Есть GPS приёмник, который выдаёт данные в NMEA. Есть Спидометр, компас, компьютер, планшет которые должны одновременно эти данные принимать и обрабатывать.растояние не более 5 метров.

При 4800 скорость приема положения, к примеру у автомобиля, да с включенным green/low power GPS (получение всего одной точки в секунду) уже не достаточна для передачи человеку данных о скорости автомобиля голосовыми сообщениями Набегает уже значимая для человека задержка (более 0.2 сек,в случае управления кнопкой - если задержка более - то кнопку просто разобьют , а GPS в low-power (выдача менее 8 точек в сек) дает уже сама задержку к 1 сек а её система фильтрации и предсказания уведет вас в столб на 100% ). В итоге такая система, как описываете, может годиться только для логирования мрашрутов, записи истории и т.д., но не для интерактивного приложения. (Из опыта создания систем голосового оповещения в авто, когда GPS только вводилось, но ещё было запрещено использование точности менее +-100 метров на территории России... Не думаю, что-то сильно изменилось )
Да - нормальная GPS дает более 500 точек в секунду - как она их передаст на 4800 Baud в 'aски' символах ?
В связи с этим вашему приложению всё равно какая задержка передачи - она всё равно будет ниже чем получаемые с таких GPS данные (и их достоверность при движении).
+ Сколько не брали датчиков, у всех есть команды переключения скорости вывода. Так-же 80% из них имеют систему встраивания собственного кода (SDK/DDK и т.д.).
Фиксированная скорость типа 4800 или 9600 в них сделана для залива конфига или прошивки, после сброса их параметров... и то, это актуально для устаревших моделей.
В большинстве новых используется 115200. Примеры: http://naviaglonass.ru/