Jump to content

    

скоростной трафик на базе ESP модуля

1 минуту назад, jcxz сказал:

PS: А зачем вам прозрачный канал? Почему не командами?

У меня и так, и так используются ESP8266.

Прозрачный режим в принципе должен экономить полосу и без того узкого UART.

В прозрачном режиме допускаю потерю данных, несмотря, на TCP (обидно).

В режиме AT-команд проблем не замечал, но и потоки большие не создавал.

При использовании собственной прошивки ESP получается так:

- TCP, пакеты по 1024 байта, 381 пакет в секунду, 381 кБ/с;

- UDP, пакеты по 1024 байта, 420 пакетов в секунду, 420 кБ/с.

ESP отправляет сгенерированный пакет на сервер. Сервер выдает эхо в ESP. ESP получает и анализирует ответ, если все Ок - тест продолжается.

По-моему, результат не фонтан.

image.png.11e6b914db270b7d789aae42eded4870.png

Share this post


Link to post
Share on other sites

Максимум что получилось выдавить из ESP8266:

- UDP пакеты по 1024 байта;

- собственная прошивка;

- данные предсгенеррированные;

- отправка непрерывная, насколько позволяет функционал SDK.

Получается 16.7 Мбит/с или 1955 пакетов/с.

image.png.0a3cbf9cc2924e92112b512ab1f1a0a1.png

Share this post


Link to post
Share on other sites
13 часов назад, adnega сказал:

У меня и так, и так используются ESP8266.

Прозрачный режим в принципе должен экономить полосу и без того узкого UART.

В прозрачном режиме допускаю потерю данных, несмотря, на TCP (обидно).

Под "зачем Вам прозрачный канал" я имел в виду прикладное назначение: для какой задачи так можно работать?

Ведь получается, раз хоть TCP, но есть потери, то для работы по каким-то стандартным протоколам (которые идут поверх TCP) это уже нельзя использовать видимо. Если только там не предусмотрен собственный механизм борьбы с потерями. Чего скорей всего не будет, раз они уже вроде как предназначены для работы поверх канала (TCP-сокета), который сам нейтрализует потери, перезапросы и гарантирует правильный порядок следования данных.

Т.е. - для практического использования такого канала, Вам видимо поверх TCP-соединения придётся запускать какой-то протокол, нивелирующий действие потерь? Мне кажется сомнительным практический смысл использования такого канала (с потерями). Если уж TCP, то брать такой вариант, который чётко работает. Ну или UDP.

 

PS: А вообще - Ваши изыскания конечно интересны. Спасибо за инфу!  :smile:

Share this post


Link to post
Share on other sites
12 часов назад, adnega сказал:

Максимум что получилось выдавить из ESP8266:

- UDP пакеты по 1024 байта;

- собственная прошивка;

- данные предсгенеррированные;

- отправка непрерывная, насколько позволяет функционал SDK.

Ещё вопрос: А Вам не встречались готовые прошивки для ESP, которые позволяют приложению во внешнем МК работать с ESP8266 в режиме аналогичном AT-командному режиму, но с бинарным протоколом обмена, а не текстовым как в AT-командах? Чтобы не эти неудобные AT-команды с чудовищным оверхедом для реализации в МК, а просто двоичными кадрами фиксированного формата обмениваться с ESP? А ещё лучше - не по UART, а по SPI например?

Share this post


Link to post
Share on other sites
38 minutes ago, jcxz said:

Ещё вопрос: А Вам не встречались готовые прошивки для ESP, которые позволяют приложению во внешнем МК работать с ESP8266 в режиме аналогичном AT-командному режиму, но с бинарным протоколом обмена, а не текстовым как в AT-командах? Чтобы не эти неудобные AT-команды с чудовищным оверхедом для реализации в МК, а просто двоичными кадрами фиксированного формата обмениваться с ESP? А ещё лучше - не по UART, а по SPI например?

Через AT отправлял бинарные данные - нормально всё приходит.

До 4 соединений TCP.

Только прошивка ESP была последняя.

Share this post


Link to post
Share on other sites
2 часа назад, jcxz сказал:

Под "зачем Вам прозрачный канал" я имел в виду прикладное назначение: для какой задачи так можно работать?

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

Обычно по такому каналу я гоняю текстовую консоль. Там трафик просто никудышный и никаких потерь не заметил. В крайнем случае, команды вернет "error" и можно переповторить.

Цитата

Ведь получается, раз хоть TCP, но есть потери, то для работы по каким-то стандартным протоколам (которые идут поверх TCP) это уже нельзя использовать видимо.

Нет такого смайлика, чтоб передать всю печаль по данной теме. Самое интересное, что кишки ESP без проблем гоняют трафик 16.7 Мбит/с (~2000 пакетов/с по 1024 байт в каждом) уже на протяжении 10 часов. Причем, и UDP, и TCP примерно одно и тоже, т.е. WiFi точно не является узким местом. Я думаю, проблема в UART и криворукости писателей AT-прошивки. Либо она не предназначена для передачи значительного потока без потерь.

2 часа назад, jcxz сказал:

Ещё вопрос: А Вам не встречались готовые прошивки для ESP, которые позволяют приложению во внешнем МК работать с ESP8266 в режиме аналогичном AT-командному режиму, но с бинарным протоколом обмена, а не текстовым как в AT-командах? Чтобы не эти неудобные AT-команды с чудовищным оверхедом для реализации в МК, а просто двоичными кадрами фиксированного формата обмениваться с ESP? А ещё лучше - не по UART, а по SPI например?

Из альтернативных пробовал только TCP2UART с форума esp8266.ru

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

Share this post


Link to post
Share on other sites
4 минуты назад, adnega сказал:

Самое интересное, что кишки ESP без проблем гоняют трафик 16.7 Мбит/с (~2000 пакетов/с по 1024 байт в каждом) уже на протяжении 10 часов. Причем, и UDP, и TCP примерно одно и тоже, т.е. WiFi точно не является узким местом. Я думаю, проблема в UART и криворукости писателей AT-прошивки.

Грусть-печаль... Напишите свой "не кривой" АТ-обработчик, чтоб быстро и без потерь, не?

Share this post


Link to post
Share on other sites
Только что, mantech сказал:

Грусть-печаль... Напишите свой "не кривой" АТ-обработчик, чтоб быстро и без потерь, не?

Проще некоторый (или весь) функционал перенести в ESP. Была бы полная документация по ESP32, я бы выбрал их.

Share this post


Link to post
Share on other sites
3 минуты назад, adnega сказал:

Проще некоторый (или весь) функционал перенести в ESP.

И намертво привязаться к этому полудокументированному чипу?? Ну нафиг, если только жутко мелкое устройство нужно.

4 минуты назад, adnega сказал:

Была бы полная документация по ESP32

Мммда, я тоже помечтал в свое время...

Share this post


Link to post
Share on other sites
38 минут назад, adnega сказал:

Обычно по такому каналу я гоняю текстовую консоль. Там трафик просто никудышный и никаких потерь не заметил. В крайнем случае, команды вернет "error" и можно переповторить.

Хех! В моём устройстве один из сокетов используется как раз для такой консоли управления. На удалённой стороне - Putty.  :smile:

До сих пор в этом проекте использовался один TCP-сокет, в основном - на приём (только сразу после открытия там передаётся HTTP-запрос, затем - только приём). И ещё один линкID - для UDP (SNTP), периодических, довольно редких. Также была сделана эта консоль управления. Давно сделана. Но почти не использовал её так как происходили эти ошибки с периодическим неответом ESP на команды отправки данных. Но времени разобраться почему так - не было. Просто не использовал этот канал связи консоли, подключался только проводом по UART консоли управления или через BT-свисток на те же провода UART (у меня консоль управления допускает разные каналы подключения и TCP-сокет - опциональный). Всё времени не было разобраться в чём там дело.

Но недавно решил добавить погодный сервис (HTTP, JSON), периодический опрос сервера. И тут выяснилось, что и с ним та же беда с отправкой данных. Вот и решил всё-таки разобраться наконец-то... :scratch_one-s_head:

 

А Ваша консоль - что на удалённой стороне (на ПК)? Эмулятор терминала? Или...?

 

Цитата

Я думаю, проблема в UART и криворукости писателей AT-прошивки.

Согласен с Вами на 100%!

 

Цитата

Либо она не предназначена для передачи значительного потока без потерь.

Если она "не позволяет", то они должны были предусмотреть механизм управления потоком. Если не предусмотрели и она не позволяет работать на полной скорости порта - это всё равно значит, что прошивка кривая.

 

Цитата

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

Тогда однозначно - в сад её.

Share this post


Link to post
Share on other sites
29 минут назад, jcxz сказал:

Тогда однозначно - в сад её.

Проверил TCP2UART (v0.6.4). Потери ~44% для потока 128 кБ/с, причем снизил скорость UART до 2.5 Мбит/с.

Современные китайские AT-прошивки хоть и теряют байты, но не половину потока.

Share this post


Link to post
Share on other sites

Из хороших новостей:

- потери победил. пришлось включить аппаратное управление потоком;

- стабильно работает на скорости UART 5 Мбит/с.

image.png.f4a5bd8d59b6c6e1ca208fd1c152a9c7.png

Из плохого:

- на ESP-01 пин 13 (U0_nRTS; он же MTDO, GPIO15) жестко сидит на земле;

- простои на шине могут достигать тысяч мс;

- максимальный поток примерно 2.5-3.0 Мбит/с (50 % от полосы UART и 18% от максимума, получаемого спецпрошивкой).

Для информации:

- пин nRTS взлетает на 8 мкс примерно каждые 100 байт;

- максимальное значение активности nRTS не измерял;

- максимальный размер пачки, который гарантировано не страгивал бы nRTS не выяснял.

Share this post


Link to post
Share on other sites

После перехода на прошивку ESP v0.60 хотя в целом всё сразу заработало, но иногда происходили странные сбои.

Сейчас нашёл их причину - оказывается в этой прошивке увеличен максимальный размер блока данных приходящих в сообщении "+IPD". Раньше этот размер не превышал 2КБ, а сейчас иногда регистрирую блоки размером до <=5840 байт. На это у меня ПО не было рассчитано. В связи с чем возникает вопрос: Какой максимальный размер блока данных "+IPD" может быть? Почему-то в мануале по AT-командам об этом ни слова.  :sad:  Только максимальный размер блока на передачу указан. Может где-то ещё можно посмотреть?

Share this post


Link to post
Share on other sites
17 minutes ago, jcxz said:

После перехода на прошивку ESP v0.60 хотя в целом всё сразу заработало, но иногда происходили странные сбои.

Сейчас нашёл их причину - оказывается в этой прошивке увеличен максимальный размер блока данных приходящих в сообщении "+IPD". Раньше этот размер не превышал 2КБ, а сейчас иногда регистрирую блоки размером до <=5840 байт. На это у меня ПО не было рассчитано. В связи с чем возникает вопрос: Какой максимальный размер блока данных "+IPD" может быть? Почему-то в мануале по AT-командам об этом ни слова.  :sad:  Только максимальный размер блока на передачу указан. Может где-то ещё можно посмотреть?

Конечно - в исходниках на github

Share this post


Link to post
Share on other sites
7 часов назад, jcxz сказал:

На это у меня ПО не было рассчитано.

В свежих АТ-прошивках можно сделать, чтоб с +IPD вываливался только link_id и размер (passive mode), а вычитывать данные можно будет ручками. Вариант?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this