[adnega 10]

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

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

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

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

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

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

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

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

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

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

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

[adnega 10]

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

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

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

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

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

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

[jcxz 183]

13 часов назад, adnega сказал:

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

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

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

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

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

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

 

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

[jcxz 183]

12 часов назад, adnega сказал:

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

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

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

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

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

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

[x893 33]

38 minutes ago, jcxz said:

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

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

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

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

[adnega 10]

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 и пароль.

[mantech 33]

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

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

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

[adnega 10]

Только что, mantech сказал:

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

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

[mantech 33]

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

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

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

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

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

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

[jcxz 183]

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

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

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

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

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

 

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

 

Цитата

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

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

 

Цитата

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

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

 

Цитата

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

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

[adnega 10]

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

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

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

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

[adnega 10]

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

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

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

Из плохого:

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

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

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

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

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

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

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

[jcxz 183]

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

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

[x893 33]

17 minutes ago, jcxz said:

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

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

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

[adnega 10]

7 часов назад, jcxz сказал:

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

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