• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе 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 остается исключительно одно - для обучения начинающих, слепить эксперимент, поиграть в тамагочи, но не для рабочих устройств.
 
Сверху Снизу