Есть ли на модулях ESP32+PSRAM нормальный многопользовательский Web со всеми актуальными настройками WiFi?

[pvvx]

А дальше там у примеров в CycloneTCP для ESP32 многие include уже устарели для текущей версии IDF, наверно как и названия процедур в http_server_demo\main\cyclone_tcp\drivers\wifi\esp32_wifi_driver.c
Т.е. ESP32 заброшен у CycloneTCP

 

[pvvx]

В итоге возникает вопрос - где взять default_event_handlers, который объявлен в CycloneTCP_SSL_SSH_CRYPTO_Open_2_0_0\cyclone_tcp\drivers\wifi\esp32_wifi_driver.c как

//System event handlers
extern system_event_handler_t default_event_handlers[SYSTEM_EVENT_MAX];

 

[pvvx]

В итого выяснилось - у Espressif какие-то проблемы с чужими TCP стеками

Bot Challenge

Ну а раз так - проверим что же все эти годы делали Espressif и до чего они дошли с ESP32, раз не дают использовать другие варианты, кроме своих (и для своих? )....

Возьмем примерище из esp-idf\examples\protocols\http_server\file_serving и натравим на него apache-jmeter:

Блин - никак...

A - модуль SPIFFS полчаса форматировал....
Счас.... назначим 5 тредов чтения и будем читать /favicon.ico




Очень круто - 4 соединения в секунду при двух ядрах и пол ГГц

 

[pvvx]

Я очень рад за Espressif - все его модули направляются на полку, а потом в помойку...

 

[A_D]

Я очень рад за Espressif - все его модули направляются на полку, а потом в помойку...

Мда, можно было не кормить их

Заказал для эксперимента пару модулей TTGO T-Energy
Уже пришли.

 

[DyadyaGenya]

Я очень рад за Espressif - все его модули направляются на полку, а потом в помойку...

Тоесть вы сделали выбор в пользу ESP32 TTGO? Никак не могу понять, что это такое. Другой производитель? Вроде как использует те же ESP32. Или не те?

 

[pvvx]

Тоесть вы сделали выбор в пользу ESP32 TTGO? Никак не могу понять, что это такое. Другой производитель? Вроде как использует те же ESP32. Или не те?

Да ничего на ESP32 не будет работать с TCP устойчиво, если сами всё с нуля не перепишите и обязательно все либы, включая WiFi.
Они годятся исключительно в варианте кое-как быстро что-то слепить для теста или в целях обучения борьбе с глюками... Т.е. в самый раз для начинающих.

 

[DyadyaGenya]

Да ничего на ESP32 не будет работать с TCP устойчиво, если сами всё с нуля не перепишите и обязательно все либы, включая WiFi.
Они годятся исключительно в варианте кое-как быстро что-то слепить для теста или в целях обучения борьбе с глюками... Т.е. в самый раз для начинающих.

А если для понятия куда стремится, то что может нормально с вайфай работать, и соответственно с tcp?

 

[pvvx]

А если для понятия куда стремится, то что может нормально с вайфай работать, и соответственно с tcp?

Linux. Для стека TCP нужна память. Для динамического распределения памяти нужна MMU. Без неё = дефрагментация "кучи" (Heap RAM) и вылет системы.

 

[pvvx]

What is Heap Fragmentation?

Heap fragmentation is a ubiquitous problem in Arduino programs, and yet it’s mostly unknown. We’ll see what fragmentation is, and how to fight against it.

cpp4arduino.com

 

[pvvx]

А если для понятия куда стремится, то что может нормально с вайфай работать, и соответственно с tcp?

C WiFi ныне обязательно нужны фичи WiFi6. Иначе очень быстро наступают ограничения кол-ва устройств у одной AP и в одном объеме.
Частично это можно решить переходом на 5ГГц, но типовые ESP этого не умеют, как и не умеют поддерживать фичи WiFi6.
Для городских квартир возможно и хватит одного или пары роутеров WiFi ещё надолго. Но для собственного дома или загородного хозяйства уже давно не хватает.
По этому WiFi уходит в часть для коммуникации-соединения нескольких сетей и грузить WiFi роутеры мелкими датчиками = потерять скорости и надежность всей сети.
От этого и развиваются всякие BLE/Zigbee.
К примеру у меня дом-мастерская имеющая всего 6x6 на сегодня имеет более 60 устройств-датчиков. Какой роутер WiFi это выдержит и какой смысл плодить WiFI роутеры, если охвата одного достаточно?
По этому большая часть датчиков на BLE. И все, у кого кол-во датчиков и исполнительных устройств большое обычно переходят на ZigBee или BLE, т.к. надежность работы такой структуры выходит сильно выше...
За 2 года в среднем я передергиваю WiFi устройства каждую неделю. Они виснут или не могут найти Роутеры. Т.е. на 20 устройств WiFi надежность работы равна максимум 1 неделя до сбоев.

 

[cryptozoy]

ESP32-C6 is Espressif’s first Wi-Fi 6 SoC integrating 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE) and the 802.15.4 protocol

 

[pvvx]

ESP32-C6 is Espressif’s first Wi-Fi 6 SoC integrating 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE) and the 802.15.4 protocol

Основная причина вылетов устройств WiFi указана в прошлых сообщениях - отсутствие MMU или малая RAM, недостаточная для статического распределения буферов необходимых для TCP и прочих функций.
Интеграция WiFi с IP/TCP достаточно сложная и ошибок в коде всегда будет иметь больше, чем в BLE или ZigBee.
Связываться с разгильдяйством ESP - вредить самому себе.
Есть ещё присущая WiFi проблема - автономность устройств. Требуют более мощный блок питания, что уменьшает надежность. Дохнут емкости в сетевых БП...
За 2 года заменено уже 3 БП из 10, где они были отдельные и один встроенный отремонтирован.
Очень прикольно ездить специально в город, чтобы сменить БП в квартире, в которой пока никто не живет (ждет когда дети пойдут в какие высшие уч.заведения).


@cryptozoy - ESP32-C3 для игры в тамагочи пойдет и давно есть, скоро тоже пойдет в помойку.

 

[pvvx]

ESP32-C6 is Espressif’s first Wi-Fi 6 SoC integrating 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE) and the 802.15.4 protocol

Нет там ничего нужного. Espressif "Несмогла" сделать ничего из WiFi6. Жрет всё так-же, а уже древние RTL при соединении (типа в спящем режиме) с AP имеют среднее потребление 1 мА.
Не из-за технологии производства чипа, а за счет поддержки фич WiFi6.

 

[pvvx]

Если вернуться к теме - покажите хотя-бы такое где монстр с 2Мегабайта SRAM+DRAM жрет до 1 мА при подключении к AP.
И держит сотни соединений в секунду по Web, не выдавая ошибок в тестах.
Тогда будет возможно обратить взгляд на более дорогой ESP32-С6.

 

[pvvx]

Но главное что опять кривое в ESP32-С6 - совмещение BT и WiFi антенны. В gihub связанных с BLE, 90% вопросов по BLE возникает у пользователей ESP устройств. Ничего в такой связке WiFi<->BLE не работает стабильно.
Там стандартно использование BLE-MQTT, т.е. к TCP глюкам добавлены ещё MQTT глюки и всё это на C++ со string, от чего самая большая фрагментация RAM кучи. Потом лепят претензии по выкидыванию нелепых показаний в HA от датчиков BLE и рваных отображаемых графиках, с постоянными пропусками приема и дикой посадкой батарей у BLE устройств связывающихся с ESP.
У BLE тайминги ожидания ответов в сотню мкс. За это время никакой ESP не успевает обработать полученные данные и устройство дублирует запросы-ответы. Но дети ещё включают вывод в UART отладочных сообщений из SDK...
В итоге BLE устройство только и занято передачей дублей, пока ESP не сообразит. При типичном соединении это выливается в увеличение потребления и времени передачи у BLE устройства в сотни раз.

 

[pvvx]

Вот графики для сравнения потребления BLE устройства при передаче 50 коротких блоков c максимально оптимизированном коде на ESP с не включенным WiFi и вообще чем либо кроме BLE.
Найдите различие
"Зато работает!"

 

[pvvx]

C WiFi ситуация для ESP аналогична. Тайминги запрос-ответ у ESP ужасающие. (Про Arduino вообще разговор не идет)

 

[pvvx]

В итоге на ESP WiFi ни датчики движения, ни датчики выключателей и особенно разнесенных ПИД регуляторов не работают по человечески, т.к. реакция человека - действие-ответ приемлемо на уровне до 200 мс, а у прочих устройств требуется ещё быстрее.
Сферой применимости ESP остается исключительно одно - для обучения начинающих, слепить эксперимент, поиграть в тамагочи, но не для рабочих устройств.

 

[DyadyaGenya]

В gihub связанных с BLE, 90% вопросов по BLE возникает у пользователей ESP устройств

Что-то я упускаю. Разве есть BLE устройства без ESP?