jcxz 235 3 июня, 2019 Опубликовано 3 июня, 2019 · Жалоба 5 часов назад, adnega сказал: Я пользуюсь v1.6.2 ESP8266_AT_Bin_V1.6.2_0.zip Прошилось. Работает. Но периодически (примерно каждые 21 секунду) ESP отключается от WiFi. Может там какой WDT появился и нужно что-то делать с ним? В моём мануале по AT-командам ничего про это нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 9 часов назад, jcxz сказал: Прошилось. Работает. Но периодически (примерно каждые 21 секунду) ESP отключается от WiFi. Может там какой WDT появился и нужно что-то делать с ним? В моём мануале по AT-командам ничего про это нет. Не замечал такого. Вы какую модель модуля используете? Нужно проверить питание и все подтяжки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 3 часа назад, adnega сказал: Не замечал такого. Вы какую модель модуля используете? Нужно проверить питание и все подтяжки. Мои все 3 модуля примерно такие: https://ru.aliexpress.com/item/Free-shipping-ESP8266-serial-WIFI-wireless-module-wireless-transceiver/32341788594.html?spm=a2g0s.9042311.0.0.274233edb9hvgc У меня с этими подтяжками и питанием прошивка AT version:0.25.0.0(Jun 12 2015 20:26:28) SDK version:1.1.2 проработала год примерно. В режиме почти ежедневной многочасовой работы. Питание там нормальное - источник мощный. Да и таких проблем больше ни с какой другой прошивкой ESP не наблюдается. Вчера перепробовал разные прошивки (которые у меня были) с целью - выяснить максимальную скорость стабильной работы UART. У меня были следующие (3 модуля): 1. AT version:0.25.0.0(Jun 5 2015 16:27:16) SDK version:1.1.1 http://esp8266.ru/ 2. AT version:0.25.0.0(Jun 12 2015 20:26:28) SDK version:1.1.2 http://esp8266.ru/ 3. AT version:0.40.0.0(Aug 8 2015 14:45:58) SDK version:1.3.0 Ai-Thinker Technology Co.,Ltd. Build:1.3.0.2 Sep 11 2015 11:48:04 Тестил в таком состоянии: 1 TCP-сокет исходящее соединение (внутри домашней сети), скорость небольшая (как говорит роутер - ~ 38kbps); только одно соединение, других нет. 1-я и 2-я - примерно одинаково работают. Методом проб установил, что с этими прошивками стабильно работает на скорости UART == 700000 бод. При 800000 бод уже появляется проблема с периодическим неответом на команду отправки данных. Тестил 700000 бод долго - полчаса точно. Так что думаю это - примерно потолок для этих прошивок. 3-ю прошивку из списка тестил мало - показалось что она не лучше чем первые 2 по скорости UART, но были какие-то ещё там отличия. Затем попробовал Вашу прошивку, но наткнулся на описанную выше проблему с периодической (21 сек) перезагрузкой WiFi. Больше не тестил. Затем нашёл у себя на диске валявшуюся прошивку: AT version:0.60.0.0(Jan 29 2016 15:10:17) SDK version:1.5.2(80914727) http://esp8266.ru/ Прошил её. И о чудо! - она стабильно работает в условиях указанного теста на скорости UART == ~1843200 бод! Гонял её на указанном тесте примерно 1.5 часа (потом уснул ;) Так что видимо как я и думал - проблема не в аппаратном FIFO или аппаратных ограничениях ESP8266, а как всегда - в кривых прошивках. Так что пока наверное остановлюсь на этой прошивке. Никаких проблем вроде пока с ней не наблюдается. Но надо тестить гораздо дольше и по-разному. Да и другие модули на неё перешью. PS: Так что скорость 1843200 бод по UART для ESP8266 - реальна! Если быть совсем точным, то реальная скорость работы UART моего STM32F429 == 1860465.1 бод. При этом ESP8266 даётся команда: "AT+UART_CUR=1843200,8,1,0,0". PPS: В данный момент эта прошивка работает в таком режиме (скорости даны такими как их показывает WiFi-роутер): link_ID=2: <= 15 kb/s - исходящий поток на TCP-сокет в локальной сети (вывод в эмулятор терминала); link_ID=1: <= 210 kb/s - входящий поток из интернета (онлайн-радиостанция); link_ID=0: используется периодически для кратковременных соединений, разделяется SNTP-клиентом и службой погоды (http://api.openweathermap.org). И вроде пока без проблем. Конечно в таком режиме навигация по меню в эмуляторе терминала подтормаживает - на нажатия клавиш реагирует с задержкой примерно наверное в 0.5 сек. При отключении от онлайн-радиостанции задержки в терминале пропадают. Понятно что поток 200 кб/с всё-таки занимает существенно и канал и ESP. Но по-крайней мере без глюков. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aner 5 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба При таком тесте примерно 1.5 часа ... какой процент ошибок показал, или пере-повторов/запростов ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 3 минуты назад, Aner сказал: При таком тесте примерно 1.5 часа ... какой процент ошибок показал, или пере-повторов/запростов ? О каких ошибках или повторах речь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 1 hour ago, jcxz said: PS: Так что скорость 1843200 бод по UART для ESP8266 - реальна! А что так все запали на ESP? Во, берем SX-ULPAN-2401-SHIELD на Qualcomm Atheros 4004. Подключаемся по SPI на 30 МГц и получаем честные 7 Mbit/s без танцев и прошивок. Или обязательно нужно китайское? Эт такой тренд уже пошел? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 3 minutes ago, AlexandrY said: получаем честные 7 Mbit/s Если честные, то 1.5, судя по картинке :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 23 минуты назад, AlexandrY сказал: Во, берем SX-ULPAN-2401-SHIELD на Qualcomm Atheros 4004. Подключаемся по SPI на 30 МГц и получаем честные 7 Mbit/s без танцев и прошивок. Во-первых: мне нужнее TCP, а не UDP. Во-вторых: на рекламных картинках всегда всё красиво и беззаботно, а когда начинаешь реально использовать, вот тогда грабли и вылезают. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 27 minutes ago, aaarrr said: Если честные, то 1.5, судя по картинке :) Эт были тесты на разных скоростях SPI и с разной длиной пакетов. Где что, я уже не помню. Важно что на 7 mbit по UDP не было потерь! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 7 часов назад, jcxz сказал: Прошил её. И о чудо! - она стабильно работает в условиях указанного теста на скорости UART == ~1843200 бод! Не понял. На этой скорости можно создать поток 180 кБ/с. Вы его создавали или удовлетворились 4 кБ/с (38kbps)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 9 минут назад, adnega сказал: Не понял. На этой скорости можно создать поток 180 кБ/с. Вы его создавали или удовлетворились 4 кБ/с (38kbps)? Там всё описано в моём посте что создавал. Не создавал, так как в этом проекте такой исходящий поток не нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 1 минуту назад, jcxz сказал: Там всё описано в моём посте что создавал. Не создавал, так как в этом проекте такой исходящий поток не нужен. В таком случае с выводами про FIFO/DMA вы поторопились. У меня UART работает на 5 Мбит/с. Отправляю пакеты по 32 байта 1000 раз/с. Итого 31.25 кБ/с. Потерь нет. Если пакетами по 64 байта, то потери есть, но очень мало 0.12% Причем, потери не сетевого плана. Сделал спецпоток, в котором очень легко видеть выпадающие куски. По-моему, данные теряются при приеме UART. Создается впечатление, что иногда срабатывает функция, блокирующая прерывания UART, что приводит к потере данных. Время блокировок в потоке 250 кБ/с (пакет 256 байт) доходит до 500 мс, потерь 5.5%. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 10 минут назад, adnega сказал: В таком случае с выводами про FIFO/DMA вы поторопились. Про DMA я ничего не говорил, так как ничего не знаю про него в ESP. А вывод, что дело (в моём случае) не в каких аппаратных ограничениях ESP я сделал на том основании, что с прошивкой v0.25 у меня происходили сбои (на 1843200 бод непрерывная передача продолжалась обычно не более пары минут), а с прошивкой v0.60 на том же самом модуле - сбоев нет длительное время. Т.е. - изменился только софт и работа наладилась. Значит дело - софте, а не в FIFO или каких-то других аппаратных плюшках. 10 минут назад, adnega сказал: У меня UART работает на 5 Мбит/с. Отправляю пакеты по 32 байта 1000 раз/с. Итого 31.25 кБ/с. Потерь нет. ... По-моему, данные теряются при приеме UART. Создается впечатление, что иногда срабатывает функция, блокирующая прерывания UART, что приводит к потере данных. У меня потерь нет, так как у меня не прозрачный режим передачи. Да и Ваши 31 кБ/сек - это далеко не то, что мои 38 кб/с, так как у вас это только передача чисто данных. А у меня 38 кб/сек - чисто данные (по эфиру). А по UART при этом может передаваться больше. Но! В моём случае моё ПО даёт команды отправки данных в UART такие, что собственно тело данных в них может достигать максимально допустимого значения == 2048 байт. После которого (по протоколу) я ожидаю подтверждения приёма от модуля. А это собственно - такой способ управления потоком в его сторону. А значит - если в пределах тела == 2048 байт переполнения чего бы там ни было внутри модуля не произошло, то и ни в каком другом случае его не будет происходить. И мой тест - более тяжёлый чем Ваш, потому что у вас только по 64 байта передаётся, а у меня - по 2048 байт иногда. Да и вообще - ваши потери вообще не относятся к моему случаю и никак не говорят о работе UART ESP, потому что в вашем случае (прозрачного канала) нет управления потоком (по UART в сторону ESP) и, если на уровне TCP-сокета управление потоком реализовано криво внутри ESP или на удалённой стороне - то потери будут из-за этого, а не из-за работы UART-а. Отсутствие управления потоком в прозрачном канале - это один из главных его минусов. Поэтому стараюсь не использовать такой режим нигде. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 20 минут назад, jcxz сказал: И мой тест - более тяжёлый чем Ваш, потому что у вас только по 64 байта передаётся, а у меня - по 2048 байт иногда. Отправляю пакет размером 2920 байт (1460 * 2) 25 раз/с = 71 кБ/с = 710 кб/с. Потерь нет. Скорость UART 5 Мбит/сек. Большие пакеты - благо. Кста, на ESP32 все ужасно - он переставляет блоки, полученные по UART! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 235 4 июня, 2019 Опубликовано 4 июня, 2019 · Жалоба 53 минуты назад, adnega сказал: Отправляю пакет размером 2920 байт (1460 * 2) 25 раз/с = 71 кБ/с = 710 кб/с. Потерь нет. Скорость UART 5 Мбит/сек. Большие пакеты - благо. Кста, на ESP32 все ужасно - он переставляет блоки, полученные по UART! Ну так и прошивку ESP8266 китайцы получается к версии 0.60 только более-менее допилили. А сколько лет прошло. Так что через N лет может и на ESP32 будет всё нормально Раз у вас отправляется 2920 байт нормально, тогда и с командной отправкой должно работать. PS: А зачем вам прозрачный канал? Почему не командами? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться