• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Есть ли на модулях 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 стеками :)

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

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

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

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

1606578702332.png


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

pvvx

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

pvvx

Активный участник сообщества
Тоесть вы сделали выбор в пользу ESP32 TTGO? Никак не могу понять, что это такое. Другой производитель? Вроде как использует те же ESP32. Или не те?
Да ничего на ESP32 не будет работать с TCP устойчиво, если сами всё с нуля не перепишите и обязательно все либы, включая WiFi.
Они годятся исключительно в варианте кое-как быстро что-то слепить для теста или в целях обучения борьбе с глюками... Т.е. в самый раз для начинающих.
 
Да ничего на ESP32 не будет работать с TCP устойчиво, если сами всё с нуля не перепишите и обязательно все либы, включая WiFi.
Они годятся исключительно в варианте кое-как быстро что-то слепить для теста или в целях обучения борьбе с глюками... Т.е. в самый раз для начинающих.
А если для понятия куда стремится, то что может нормально с вайфай работать, и соответственно с tcp?
 

pvvx

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

pvvx

Активный участник сообщества
 

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 неделя до сбоев.
 

pvvx

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


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

pvvx

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

pvvx

Активный участник сообщества

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... :eek:
В итоге BLE устройство только и занято передачей дублей, пока ESP не сообразит. При типичном соединении это выливается в увеличение потребления и времени передачи у BLE устройства в сотни раз.
 

pvvx

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

pvvx

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