[csm7 0]

Доброго времени суток

Необходимо по WiFi с максимальной скоростью передавать большие файлы

ESP8266 или ESP32 поддерживают возможность

высокоскоростной передачи (значительно более 115000 бод)

Изменено 2 февраля, 2018 пользователем csm7

[Proton 1]

ESP8266 в локальной сети может передавать со скоростью до 8 МБит/сек, на сервер в интернет значительно медленнее, зависит от пинга. Пример хороших исходников для этого модуля: TCP2UART переходник с настройкой по Web.

[jcxz 243]

Интересно: а какую максимальную скорость исходящего трафика можно получить на ESP8266 на AT-командных прошивках? И чтобы работало стабильно, без глюков.

Не обязательно чтобы протокол был именно AT-командами, можно любой другой, позволяющий внешнему МК через UART управлять работой ESP: устанавливать/закрывать TCP/UDP-соединения (только хотя-бы исходящие), передавать блоки произвольных данных.

В своём проекте я пробовал разные AT-командные прошивки, но если на малых скоростях потока и на входящих потоках все они работают более-менее стабильно, то при увеличении скорости иногда происходит зависание обмена на ожидании ответа на одну из команд отправки данных. На всех прошивках такое наблюдается. Может я что-то не понимаю в куцей документации или где-то ошибка в коде. А может сами AT-командные прошивки ESP8266 кривые?

 

PS: Кто-нить имеет опыт работы с AT-командными прошивками ESP8266? Именно с исходящим потоком данных?

[adnega 11]

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

Интересно: а какую максимальную скорость исходящего трафика можно получить на ESP8266 на AT-командных прошивках? И чтобы работало стабильно, без глюков.

Если подразумевается AT-прошивки, то источником данных будет UART0 модуля.

Я запускал порт на 3.3 Мбит/сек в прозрачном режиме - некоторые данные (~8%) терялись (вроде, у ESP8266 нет DMA на UART).

По-моему, узким горлышком будет UART.

 

Пример теста:

rx_count = 97278080, // принято байт

tx_count = 106877488, // отправлено байт
tx_time = 320s, // время теста
tx_speed = 326kB/s, rx_speed = 296kB/s, // скорости потока
delta = 9599408B, delta% = 8 // потери

[jcxz 243]

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

Если подразумевается AT-прошивки, то источником данных будет UART0 модуля.

Я запускал порт на 3.3 Мбит/сек в прозрачном режиме - некоторые данные (~8%) терялись (вроде, у ESP8266 нет DMA на UART).

По-моему, узким горлышком будет UART.

Да, они родимые.

Вы работали только в прозрачном режиме? А AT-командами не пробовали передавать?

Прозрачный мне не подходит: нужно несколько одновременных соединений, нужно управлять ими (подключение/отключение), нужен UDP.

Сейчас у меня работает стабильно на приём (TCP-сокет) на скорости UART-а == 1843200 бод. Может сутками качать. Проблема с передачей.

 

PS: Сейчас ещё раз пересмотрел свои старые сообщения в этой ветке и "мануал" на ESP8266 и возникла мысль, что возможно проблема в скорости порта. В своих прежних тестах я тестил на 460800 бод и передача работала стабильно. Но сейчас нужно выше - хотя-бы 921600 бод. Просмотрел ещё раз мануал и возникло подозрение, что проблема может быть в скорости UART. Надо попробовать скорость 1152000 бод.

 

PPS: А какие скорости UART Вы ещё пробовали с ESP8266? На какой максимальной работало стабильно (если такая была)?

 

[adnega 11]

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

что возможно проблема в скорости порта. В своих прежних тестах я тестил на 460800 бод и передача работала стабильно. Но сейчас нужно выше - хотя-бы 921600 бод. Просмотрел ещё раз мануал и возникло подозрение, что проблема может быть в скорости UART. Надо попробовать скорость 1152000 бод.

 

Скорость получается путем целого деления частоты 80МГц.

Т.е. 921600 точно не получить: либо /86 = 930232 (+1%), либо /87 = 919540 (-0.2%).

Но дело не в этом, а в том, что без DMA на высоких скоростях байты могут потеряться. Вроде, в ESP32 уже есть DMA на прием по UART.

[jcxz 243]

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

Скорость получается путем целого деления частоты 80МГц.

Т.е. 921600 точно не получить: либо /86 = 930232 (+1%), либо /87 = 919540 (-0.2%).

Почему 80МГц? В мануале указано: "Baudrate range: 110 to 115200*40 (4.608 Mega)". Т.е. - 921600 легко получается и делитель целый. Разве что только нечётный.

Цитата

Но дело не в этом, а в том, что без DMA на высоких скоростях байты могут потеряться. Вроде, в ESP32 уже есть DMA на прием по UART.

Вы невнимательно прочитали моё сообщение: У меня сейчас стабильно (по многу часов кряду) работает приём с TCP-сокета хоть на 921600 хоть на 1843200. Но только приём от ESP в мой внешний МК. Если ESP8266 может передавать по UART на такой скорости (хоть с DMA хоть без), то и с приёмом с UART-а у него не должно быть проблем. Единственное конечно, что когда он передаёт, он сам тайминги формирует, а когда принимает - должен с таймингами внешнего МК работать. Вот тут может быть проблема.

[adnega 11]

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

Единственное конечно, что когда он передаёт, он сам тайминги формирует, а когда принимает - должен с таймингами внешнего МК работать.

Ключевой момент не тайминги, а переполнение (OVR) при приеме данных. Там есть FIFO, но я не понял как его 128 байт распределяются между RX/TX и UART0/1.

Цитата

When the hardware logic receives the data, it will fill them into receiver FIFO. Program
should withdraw the data timely ,the data-dequeue is also a process of deleting data from
FIFO automatically,thus, there will be one more vacancy in receiver FIFO. If the data in the
receiver FIFO can not be removed in time, the receiver FIFO will be full which makes data
loss.

Цитата

Both UART0 and UART1 have a length of 128 Byte hardware, read and write FIFO
operations are at the same address.
The hardware registers of two UART module are the same, and distinguished by macro
definitions of UART0 / UART1.

 

[jcxz 243]

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

Ключевой момент не тайминги, а переполнение (OVR) при приеме данных. Там есть FIFO, но я не понял как его 128 байт распределяются между RX/TX и UART0/1.

Ну это - аппаратное FIFO UART-ов. То что оно 128 байт - не обязательно говорит, что оно будет переполняться при бОльших размерах пересылок. Я передаю блоки данных размером <= 2048 Б (максимум позволяемый AT-командами) и по-большей части ESP8266 их нормально принимает. До какого-то времени. И только на какой-то N-й блок он не отвечает.

[adnega 11]

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

До какого-то времени. И только на какой-то N-й блок он не отвечает.

А версия прошивки/SDK какая?

Цитата

AT+GMR
AT version:1.6.2.0(Apr 13 2018 11:10:59)
SDK version:2.2.1(6ab97e9)
compile time:Jun  7 2018 19:34:26
Bin version(Wroom 02):1.6.2
OK

Я такую использую. Доволен.

[jcxz 243]

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

А версия прошивки/SDK какая?

У меня всего 3 модуля с ESP8266. Все с разными прошивками. Два - v0.25 (один SDK 1.1.1 другой SDK 1.1.2), 3-й ESP8266 с v0.60. Вроде так, не уверен точно за цифры - позже гляну точно.

Перепробовал работу со всеми. Ведут себя все одинаково (в плане передачи).

[adnega 11]

Это очень старые прошивки. Рекомендую обновить. Они вообще после некоторого времени перестают даже на ARP-запросы отвечать (прописывал ARP вручную).

Но, обращаю внимание, что современные обновления требуют 1 МБайт флеши, а старые обычно выпускались с 512 кБ.

[jcxz 243]

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

Это очень старые прошивки. Рекомендую обновить. Они вообще после некоторого времени перестают даже на ARP-запросы отвечать (прописывал ARP вручную).

Но, обращаю внимание, что современные обновления требуют 1 МБайт флеши, а старые обычно выпускались с 512 кБ.

У меня они все на 512КБ. Но работают уже не первый год. С ARP может и есть проблемы, но я их использую только для исходящих соединений - значит не критично.

Обновить на что? Можете какую-то версию порекомендовать? Для 512КБ.

 

PS: Насколько помню из толковищ на форумах - для 512КБ просто будет недоступно обновление по воздуху. Может ещё что-то. Некритичное.

[adnega 11]

Я пользуюсь v1.6.2

ESP8266_AT_Bin_V1.6.2_0.zip

[adnega 11]

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

 Насколько помню из толковищ на форумах - для 512КБ просто будет недоступно обновление по воздуху. Может ещё что-то. Некритичное.

Начиная с v1.7 в принципе нет варианта на 512 кБ.