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

Энергопотребление ESP-WROOM-32

pvvx

Активный участник сообщества
И вообще в 2018 году модули без поддержки ssl для новых проектов уже не могут использоваться поэтому забываем о существовании esp8266. То же относится и к rtl8710af
Относится и к ESP-32 пока он без нормальной поддержки psRAM.
Вообще мы тут разбираем устаревшие чипы лет на 5-ть, самого низкого ценового диапазона. Т.е. второй или третий (короче последний) производственный эшелон.
Более менее современный WiFi-SoC и изготовленный по новым нормам массовых технологий стоит в часиках Apple... Там совсем другие ТТХ и интеграция в SoC, да и кол-во, оборот производства их...
Nikolz у нас занят раскопкой могил (некромант?) практически десятилетней давности. Я думаю ему можно взять что и более старое... Цена там никакая, т.е. оплата в минус за складирование и утилизацию...

Ну и на счет энергопотребления модуля ESP-32 – тут всё просто – оно от 0.45 мкА (reset) до 500 мА (передача WiFi) и находится в зависимости от писателей ESP-IDF. Любой доступ, с манипуляцией токов WiFi пользователю – закрыт, как и у ESP8266. Дано выбрать всего пару режимов, созданных для Arduino совместимости и ни шагу в сторону.
 
Последнее редактирование:

nikolz

Well-known member
Вы все перепутали. Кроме того выбор чипа зависит от отношения времени спячки к времени активности.

ESP32 обеспечивает работу с датчиком вообще без просыпания только силами ulp. Ток получается вообще недосягаемый для 8266.

ESP32 то же делает сам без дополнительных приблуд.

И вообще в 2018 году модули без поддержки ssl для новых проектов уже не могут использоваться поэтому забываем о существовании esp8266. То же относится и к rtl8710af
перепутал - это когда штаны через голову надевают.
я же лишь высказал свое резюме.
-----------------------------
Безусловно, использование ULP выгоднее, чем CPU ESP8266.
Но это смогут сделают единицы из тех, кто на этом форуме - это раз.
Если же включить основной проц, то потребление будет минимум в 2.5 раза больше (от 35.. 110 ма вместо 14..17).
Включение же WIFI( по вашим измерениям) дает скачек тока в два раза и эти 400-500 ма за 0.1 секунды съедят все что вы сэкономили за 10 секунд.
Пример (не мой) на который я дал ссылку и комментарии к нему лишь подтверждает тот уровень решения на ESP32, который будет у большинства.
----------------------
Поэтому, лучшее доказательство того, что ESP32 экономичнее - это график потребляемого тока в сравнении с ESP8266.
Пока я не сделал это.
Если Вы хотите, то вот условие задачи, которую надо реализовать (по крайней мере это типовой алгоритм, который я использую на ESP8266 и результаты исследования выкладывал на форуме)
------------------------------------
Постановка задачи:
Устройство периодически входит в режим deep-sleep на время T(10...30..600) сек.
Для определенности возьмем 30 сек.
При просыпании устройство читает показания датчика 0.1 сек, передает по WIFI UDP данные, включая предыдущие, если они не переданы, на сервер, получает подтверждение.
Если подтверждения нет в течении 20 мс, то посылает повторно данные и ждет подтверждение.
Если подтверждения нет три раза, то запоминает данные и ложиться спасть.
Минимальное время активности WIFI 0.3 сек.
-------------------------------
И еще замечу следующее.
На ESP8266 мне удалось получить импульсный ток от автономного источника питания, батарейка CR3220 или солнечная панелька 8x5 см2 , при указанном алгоритме работы не более 60 ма (на форуме есть результаты).
--------------------------------------
Когда реализую это на ESP32 и получу лучше результат, чем на ESP8266, то обязательно расскажу на форуме, а пока мое мнение:
ESP8266 лучше чем ESP32 при маломощном автономном питании .
Кроме того, на ESP8266 значительно проще реализовать указанный алгоритм.
--------------------------------------------------
Что же касается чего не могут использовать модули в 2018 году. Вы это серьезно?
Т е Вы мните себя этаким законодателем гостов и внедряете свои изделия на оборонных предприятиях?
Да Вы батенька шутник.
--------------------------------
Всем успехов.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Если же включить основной проц, то потребление будет минимум в 2.5 раза больше (от 35.. 110 ма вместо 14..17).
Если заказать у кого за оплату, то будет значительно меньше у ESP-32.
Всё остальное - это ваша роспись в некомпетенции.
Поэтому, лучшее доказательство того, что ESP32 экономичнее - это график потребляемого тока в сравнении с ESP8266.
Вам уже рисовали.

Что же касается чего не могут использовать модули в 2018 году. Вы это серьезно?
Т е Вы мните себя этаким законодателем гостов и внедряете свои изделия на оборонных предприятиях?
Да Вы батенька шутник.
"Вы батенька" не бывает. Наверно надо писать "Оно ..." :)
У Они другие причины. Как-то не едут сани по асфальту... Раньше ездили, но законодатели мод требуют сертификат от 512 бит и минималку в НТ40 :) Ну не найти больше хороших подков для расходников к старым методам - кузнецы все выдохлись... Копыта до крови... Чаго могу токо вам пожелать, если впряглись в ESP8266 :)
 

nikolz

Well-known member
Взял пример deep-sleep (30 сек) для ESP32 с работающим ULP.
И ужаc какой-то:
ток в момент старта до 45 ма, больше чем у ESP8266,
время старта аж 325 мс, в разы больше чем у ESP8266 ( 85...120 мс ).
Вот картинка.
upload_2018-2-17_0-4-49.png
Хотелось бы услышать начальника транспортного цеха.
 

nikolz

Well-known member
сравнительные характеристики WROOM и WROVER.
нашел у китайцев. обратите внимание на указанный ток.
Цена WROOM уже меньше 200 руб с доставкой от 5 шт.
upload_2018-2-17_9-1-48.png
 

nikolz

Well-known member
Если отключить в ESP32 вывод сообщений при рестарте,
для этого надо подключить IO15 через резистор к GND,
то время начальной загрузки сокращается всего на 35 мс и составляет 290 мс.
upload_2018-2-17_11-24-31.png
т е пока это хуже чем у ESP8266.
 

nikolz

Well-known member
В результате внимательного прочтения документации удалось уменьшить минимальное время просыпания и засыпания примерно до 155 мс.
Остался еще один резерв - это переключить режим flash из DIO в QIO, но исследуемый модуль (вернее его флеш) не работает в QIO.
Согласно документации это долно обеспечить время примерно 138 мс.
upload_2018-2-17_14-44-17.png
Таким образом, по данному параметру ESP32 близок к ESP8266 но хуже.
upload_2018-2-17_15-2-34.png
----------------------------------
Наблюдаемые токи тоже близки к ESP8266 но немного выше.
Никаких 500 ма пока не наблюдается.
------------------------------
Посмотрим , что будет при включении WIFI.
 

pvvx

Активный участник сообщества
И ужаc какой-то:
ток в момент старта до 45 ма, больше чем у ESP8266,
У ESP8266 в стандартном SDK при старте 75 мА.
Ну вот, а говорили что ESP-32 жрет больше, а без проблем вышло наоборот.
Пытаетесь сравнить мои сборки SDK для ESP8266 с Espressif ESP-IDF? :)
Это давно всё уже произведено и даны выводы.
Никаких 500 ма пока не наблюдается.
Частота CPU не 230 МГц и нет инициализации WiFi, да используется другое ПО с которым данное не сравнивают.
Поиграйтесь ещё.
 
Последнее редактирование:

nikolz

Well-known member
У ESP8266 в стандартном SDK при старте 75 мА.
Ну вот, а говорили что ESP-32 жрет больше, а без проблем вышло наоборот.
Пытаетесь сравнить мои сборки SDK для ESP8266 с Espressif ESP-IDF? :)
Это давно всё уже произведено и даны выводы.
Частота CPU не 230 МГц и нет инициализации WiFi, да используется другое ПО с которым данное не сравнивают.
Поиграйтесь ещё.
Проверяю, что я был прав,
утверждая,
что ESP32 применимо вместо ESP8266 лишь при Не автономном питании.
------------------------------
Если бы можно было начать работу без RTOS то возможно было бы лучше.
-------------------------
А вот если бы в ESP8266 решить проблему с отключением сканирования, то ESP8266 было бы вне конкуренции с временем активности
не более 180 мс.
Сейчас у меня на ESP8266 300 мс с WIFI и 100 мс без WIFI и током CPU 14 ма.
Вот это и надо превзойти.
-------------------------------------
Вообще-то, пока получилось, что лучшее решение
это таймер от Ti + attiny85a+ ESP8266.
Получается в режиме полного сна будет работать лишь таймер и ток составит не более 1 мка.
В режиме работы ULP (attiny85a) ток потребления будет не более 150 мка при 100% работы и соответственно 1.5 мка при 1%
Ну и в активном режиме ESP8266 получаем токи указанные выше.
----------------------
Это решение превосходит ESP32 и RTL для автономного питания и по потреблению и по цене.
Вот оно для меня пока эталон.
Предложите лучше.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Если бы можно было начать работу без RTOS то возможно было бы лучше.
Сколько времени и энергии занимает полная инициализация RTOS? 2..3 us при 30 мА?
Истина в том, что вы не знаете RTOS и на основе этого строите свои выводы. Сложно осваивать что другое из-за потраченного вами времени в кол-ве нескольких лет на поверхностные ковыряния с ESP8266? Т.е. подтверждаете, что знания и методы применимые с ESP8266 не годятся для любых других более современных WiFi-SoC.
Проверяю, что я был прав,
утверждая,
что ESP32 применимо вместо ESP8266 лишь при Не автономном питании.
Повторяйте эту глупость дальше, пока не дойдет, что всё наоборот. Но ESP-32 не лучший в классе для применения в устройствах с автономным питанием. А уж устройства с ESP8266 вообще не входит в данный класс устройств из-за отсутствия необходимой встроенной аппаратной поддержки.
 

nikolz

Well-known member
Сколько времени и энергии занимает полная инициализация RTOS? 2..3 us при 30 мА?
Истина в том, что вы не знаете RTOS и на основе этого строите свои выводы. Сложно осваивать что другое из-за потраченного вами времени в кол-ве нескольких лет на поверхностные ковыряния с ESP8266? Т.е. подтверждаете, что знания и методы применимые с ESP8266 не годятся для любых других более современных WiFi-SoC.

Повторяйте эту глупость дальше, пока не дойдет, что всё наоборот.
Если не можете что-то доказать на цифрах, то не надо переходить на личности.
Так как единственная истина в ваших высказываниях - это ваше хамство.
 

pvvx

Активный участник сообщества
Если не можете что-то доказать на цифрах, то не надо переходить на личности.
Так как единственная истина в ваших высказываниях - это ваше хамство.
Ну цифр то от вас не видно. Одни рисунки, которые никто даже проверить не может.
У других все "цифры" давно выложены и дано всё, для альтернативного измерения в качестве их проверки. Вот на них и строятся мои выводы, а не на ваших "хотелках" и наскальных рисунках.

Если вы считаете себя специалистом в ESP8266 - замер отключенного CPU с активной памятью в студию. Сравним с ESP-32, т.к. это уже измерено и представлено.
Это основа всех sleep применяемого для понижения потребления тока у автономных устройств. Отношение тока в этом режиме будет говорить во сколько раз ESP-32 более походит для автономных устройств. Вторая часть данного режима, такая как время выхода-восстановления из sleep (затрачиваемая энергия на это у чипа) тоже значится. Это сложнее измерить и имеет множество нюансов при разных задачах (нужна ли активация разной периферии...).

Второй показатель влияющий на применимость для автономных устройств – наличие и возможности PMU по коммутации необходимых блоков.

И уже третий – это мА на MIPS при активности CPU. Третий по значимости, т.к. это не сильно разнится даже у разных архитектур CPU в актуальных WiFi-SoC.

Для пояснения этого вам был представлен график потребления тока у RTL8710BN при задаче приема и формирования ответа в UART символов. В него включен и старт с загрузкой SDK и выводом полного лога загрузки в LogUART.
 
Последнее редактирование:

pvvx

Активный участник сообщества
Поддержка WiFi состоит из таких задач, где нужен CPU:

1) Инициализация драйвера.
2) Обработка входящих пакетов по прерыванию от RF части.
3) Формирование пакета для отсылки в RF (запуск DMA).
4) Обслуживание таймера для арбитража.

В обработку входящих пакетов входит передача блока в LwIP и пользовательскую программу. Это наверно не более нескольких мкс при CLK в сотни MГц.

На отсылке ответа вообще время активности CPU мало. Ему всего-то надо закинуть пакет в буфер DMA… 1 мкс? :)

Перезарядить таймер арбитража – пару us хватит?

Всё остальное время CPU должен находиться в режиме sleep c активными прерываниями.

В режиме WiFi DTIM() постоянное включение модуля RF не требуется. Его включают перед приемом beacon каждые n*102.4 мкс, время появления которого от AP известно c точностью до 1 us и n из DTIN(n).
Т.е. вся задача CPU заключается в просыпании по прерыванию таймера и установки пару регистров у RF части. Далее он опять может спать до появления прерывания прима пакета от RF и таймера ограничения окна активности приема beacon у RF.

Ну и какое потребление имеем у ESP-32/ESP8266 в режиме STA c DTIM()? :) :)

В режиме AP и без активных задач приема-передачи приемник RF всегда активен и требуется постоянная передача пакета beacon c арбитражем. Время активности CPU это почти не меняет. Он может спать 99% времени.

Смотрим реализацию WiFi дров Espressif и ужасаемся - CPU постоянно активен... и только процесс IDLE в RTOS его спасет - там он сидит на команде пониженного потребления с ожиданием прерываний.
Но это всё без разницы, т.к. ПО затачивается для Arduino, в которой CPU обязан постоянно молотить loop() с поллингом...
----
Т.к. работа с WiFi имеет свои стандарты, то разница в потреблении зависит от реализации алгоритмов в самом ПО. Но и алгоритмы, включая код дров WiFi у всех одинаковы (тянуты из одного источника и имеют всего мелкие вставки и удаления ненужных частей для Arduino). Потребление мА на MIPS тоже не имеет больших различий у разных CPU. Потребление RF части так-же не отличается в разы и зависит от технологии изготовления кристалла…

Остается только время восстановления CPU из sleep (и RF части в случае STA DTIM()) с активность прерываний и реализация PMU. От этого и зависит различие потребления при поддержке WiFi. У ESP8266 ничего хорошего тут нет и не реализовано (восстановление PLL очень долгое - порядки ms, прерывания не обслуживаются, PMU вообще нет, ...).

На это есть давно известные нормативы и цифры, и они объявлены ранее…

Не путать время восстановления CPU из sleep (и потребление чипом в sleep) с deep_sleep, где требуется перезагрузка и переинициализация ОC и внутренних контроллеров.

Что там выдумывает nikolz - только ему и известно :)

Так-же пример простого автономного устройства, где применим WiFi:
https://prist.ru/produces/pdf/ikascope_ws200.pdf
C INA219 у меня такое уже есть и работает без специального ПО (web и websocket для интерактивных графиков) и цена в 10 раз меньше, как и частота опроса :)
 
Последнее редактирование:

pvvx

Активный участник сообщества
Подключить можно а чтобы работало без дополнительного питания - нельзя.
Т.е. данный роутер (RT5350) из 2010 года выходит дешевле и функциональнее ESP32-WROVER, при этом имеет полные USB и Eth...
Странно как-то, что делал Espressif все эти годы? :) Прикручивал psRAM? :)
Потребление в режиме AP у них аналогично, но MiFi не падает при питании от USB, ну если не пару метров кабель... И там же активен USB и Eth, да две антеннки (1.5)...
 
Последнее редактирование:

nikolz

Well-known member
Ну цифр то от вас не видно. Одни рисунки, которые никто даже проверить не может.
У других все "цифры" давно выложены и дано всё, для альтернативного измерения в качестве их проверки. Вот на них и строятся мои выводы, а не на ваших "хотелках" и наскальных рисунках.

Если вы считаете себя специалистом в ESP8266 - замер отключенного CPU с активной памятью в студию. Сравним с ESP-32, т.к. это уже измерено и представлено.
Это основа всех sleep применяемого для понижения потребления тока у автономных устройств. Отношение тока в этом режиме будет говорить во сколько раз ESP-32 более походит для автономных устройств. Вторая часть данного режима, такая как время выхода-восстановления из sleep (затрачиваемая энергия на это у чипа) тоже значится. Это сложнее измерить и имеет множество нюансов при разных задачах (нужна ли активация разной периферии...).

Второй показатель влияющий на применимость для автономных устройств – наличие и возможности PMU по коммутации необходимых блоков.

И уже третий – это мА на MIPS при активности CPU. Третий по значимости, т.к. это не сильно разнится даже у разных архитектур CPU в актуальных WiFi-SoC.

Для пояснения этого вам был представлен график потребления тока у RTL8710BN при задаче приема и формирования ответа в UART символов. В него включен и старт с загрузкой SDK и выводом полного лога загрузки в LogUART.
И зачем так много писать?
В моих постах написано все об эксперименте.
даже Вы в состоянии это повторить. Понимаю, у меня эксперименты простые и дятлу понятны.
Вам западло самому делать поэтому и требуете чтобы вам в студию принесли.
Типа данный форум -поле чудес ... в стране дураков.
 

pvvx

Активный участник сообщества
И зачем так много писать?
В моих постах написано все об эксперименте.
даже Вы в состоянии это повторить. Понимаю, у меня эксперименты простые и дятлу понятны.
Вам западло самому делать поэтому и требуете чтобы вам в студию принесли.
Типа данный форум -поле чудес ... в стране дураков.
Ну нет таких замеров. У других, кто представил по инет измерения на ESP8266 вышло совсем другое, чем у вас.
По этому не "в состоянии это повторить". Наверно не "дятел".
Недавно измерял ESP8266 - при старте выходит 75 мА до инициализации WiFi, а вот ваши на старте модуля 20 не выходит.
После старта можно и менее сделать, загнав CPU на [inline]asm volatile ("waiti 0;")[/inline].
Могу подробнее (для "дятла" ? :) )- пока ESP8266 грузится и отрабатывает инициализацию SDK с выводом сообщений в UART, ets_run() с командой waiti 0 не вызывается, а проц молотит на полную, да ещё с включенным RF блоком. И так пока не достигнет инициализации WiFi драйвера.
Если отключить тактирование (CLK) на RF блок програмно, то после RESET любой может измерить сколько потребляет ESP8266 на waiti 0 в цикле ets_run(), при 52 МГц CLK CPU путем перевода его в режим программирования.
 
Последнее редактирование:

=AK=

New member
И зачем так много писать?
Вопрос риторический. Всем давно известно, что когда pvvx в очередной раз обсирается, он начинает плодить горы бессмысленного флуда, чтобы тупо замести следы. Поэтому весь форум засран его постами. =:D=
 

pvvx

Активный участник сообщества
Вопрос риторический. Всем давно известно, что когда pvvx в очередной раз обсирается, он начинает плодить горы бессмысленного флуда, чтобы тупо замести следы. Поэтому весь форум засран его постами. =:D=
Ошибка - это вы меня веселите на пару с nikolz. И форум засран постами зеленых рож =AK=.
ESP уже давно помер, вышел из моды, а на форуме только вопросы раз в неделю "как включить/прошить ESP8266" :p
Я так понял, что это ваш отклик на эксперимент nikolz по впариванию ахинеи и наскальных рисунков с его хотелками?
Он уже два года добивается простого от ESP8266 -> https://esp8266.ru/forum/threads/re...-sozdanija-otkrytogo-sdk.292/page-2#post-7091 но всё никак не получить.
А уж о замерах времени соединения ESP8266 к AP он не одну тему исписал :) Но статистки и примера всё равно нуль. Ему уже давали статистику времени пересоединения к AP при разных опциях c deep_sleep c примерами, да без разрыва сессии у AP и он на время успокоился. Продлить время в deep_sleep и AP отключит отвалившуюся station :) Тут бложек Reducing WiFi power consumption on ESP8266 ему тоже выкатывали с замерами времени cоединения и тока. :) Но сравнить, как и =зеленая рожа=, ничего не могут...
 
Последнее редактирование:
Сверху Снизу