Скрыть объявление
На нашем форуме недоступен просмотр изображений для неавторизованных пользователей. Если Вы уже зарегистрированы на нашем форуме, то можете войти. Если у Вас еще нет аккаунта, мы будем рады, если Вы к нам присоединитесь. Зарегистрироваться Вы можете здесь.

Энергопотребление ESP32-WROVER в deep sleep

Тема в разделе "ESP32 - все о железе", создана пользователем sharikov, 2 фев 2018.

  1. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    При тестах было замечено, что приложения на новом SDK-IDF запускаются от источника с более высоким сопротивлением, чем у ESP8266. Это свидетельствует о том, что обычного коднера в сотни мкФ в питании для гашения пиков достаточно. Итоговую цену это сильно не меняет.
    Первые версии SDK для ESP-32 не запускались и от источника с ограничением пиков в 500 мА.
    В новой версии SDK проц заглушили по частоте, включили троттлинг для понижения потребления (в idle RTOS) и сделали из него аналог ESP8266 :) Теперь с ним можно работать по методу Arduino - опрашивая всё "поллингом" - тупо греть внешнюю среду :) (т.е. в основе удовлетворить спрос на методы у телепузиков).
    Замер приема это и показывает - 700..800 килобайт, вместо 1.6 МБ/сек в TCP.

    Если все while(условие) заменить на ожидание в sleep прерываний, но оставить 500 МГц общую для ядра, то потребление будет в разы меньше ESP8266 при одинаковой задаче. Т.е. беда в головах, а не чипе.
    nikolz уже это продемил - включил таймер с прерыванием, заставив проц на 166 МГц исполнять while(1); в ожидании прерывания и измерив ток потребления такого чуда вывел, что чип жрет больше ESP8266 исполняющего команду wait i :) Но жестокая реальность показала, что на тех-же чипах ESP8266 не справился с задачей подготовки и вывода в ШИМ MP3 на два канала и жрет при простой поддержке приема по WiFi те-же 60..70 мА как и полностью отрабатывающий прием и декодирование программно в ШИМ на 6МГц стерео поток МP3 другой чип.
    После пояснения этого nicolz-у, он вывел - использовать новые чипы сложно и вернулся к устаревшему ESP8266... И до сих пор сравнивает именно в таком контексте потребление чипов - сравнивает ESP8266 с неактивным CH_EN, с другим чипом, выполняющий команду while(1) на всей своей ГГцовой дури. :)
     
    Последнее редактирование: 8 фев 2018
  2. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Сдул крышку, да сам модуль для очистки от возможных утечек после пайки китайцами и поставил обратно.
    (Последние замеры уже были даны с этими действиями c ESP-WROOM..).
    Походу причина понижения производительности нашлась:
    ESP-32S_CLK_FLASH_DEF.gif
    1) По умолчанию, стандартные настройки среды, частота CLK на Flash всего 40 МГц. А из неё исполняется программа...
    2) Не лезет весь основной исполняемый код RTOS и прочих стандартных задач в "кэш" Flash. Раздулся.
    В RTL серии "B" активность Flash происходит только при старте в стандартных примерах (задачах), потом не наблюдается вообще - говорит о том, что "кеща" XIP у него достаточно и туда влезает весь активный код. Частота CLK Flash у RTL-B 100 МГц.
     
  3. sharikov

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

    Сообщения:
    602
    Симпатии:
    52
    examples/wifi/power_save
    (режим light sleep: соединение с точкой доступа сохраняется)
    80MHz dualcore мощность передатчика ограничил до 14dbm
    Irun = 100ma
    Iidle = 11ma
    Iavg = ~15ma
    У rtl8710 в аналогичном режиме раза в 2 меньше.
     
  4. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Примерные значения потребления CPU + пара активных контроллеров (обобщенные замеры на разных задачах) у RTL-"серии A":
    RUN/IDLE/SLP
    166.6MHZ - 63/21/6.4 mA
    83.3MHZ - 55/15/6.4 mA
    41.6MHZ - 51/11/? mA
    20.8MHZ -49/9.5/? mA
    В специализированных (адаптированных) режимах различие достигает примерно +-1.5 раза от описаного. У RTL-"серии A", как и у ESP8266 не лучшие показатели в sleep реализованными простыми методами понижения питания с помощью спец. команды CPU (не трогая PMU).
    У RTL-"серии B" среднее потребление в режиме активного CPU/FPU 125МГц больше, но при одинаковых задачах, за счет троттлинга и PMU выходит меньше. При активности CPU добавляется XIP контроллер с 100 МГц на Flash и 32КБ "кэш".

    А у ESP-32 два ядра и при 2x80МГц должно быть около того-же.
    В режиме DTIM(n) в реальной обстановке все модули показывают среднее потребление около 15 мA при тесте за 10..20 часов активности. Различия в работе только у ESP8266. При DTIM(n) у него функционирование LwIP нарушено (понижена частота таймера основной функции LwIP по расчету тайм-аутов и прочих параметров соединений/сокетов в сотни раз и никакие сетевые стандарты он поддерживать в данном режиме не может).

    Надо запускать тест типа "DHRYSTONE" Benchmark Program Version 2.1 и измерять потребление для сравнения с другими MCU. На ESP пока таких измерений не видел (наверно тормоз и скрывают :)).
    С учетом падения производительности из-за XIP имеются большие различия первого прохода у данного теста, т.к. он влезает в "кеш" полностью...
    Ещё различий у реальных приложений наберется из-за использования ROM. У всех ESP показатель использования функций ROM очень плохой (правильнее сказать - ужасен). ROM работает без тактов ожидания, не требует "кеширования" и в итоге приложение активно использующее функции ROM потребляет меньше и работает быстрее.
     
    Последнее редактирование: 9 фев 2018
  5. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Вы забыли про свои недавние действия с замером тока на RTL8710AF?
    Так-же забыли стереть те сообщения, как вы всегда делаете и пока можно дать ссылку на них, для напоминания :)

    И опять понаписали ошибок.
    В 9-ом сообщении темы представлен ток старта ESP-32 и он не превышает 35 мА, а у ESP8266 - в два раза больше.
    Ну и далее аналогично - не очень корректные сравнения.
    Но вам потянет :)
    Единственное, с чем можно согласиться - более длительная начальная загрузка в ESP-IDF по сравнению с rapid-loader в ESP8266.
    И если приделать педаль с GPIO на RESET, то получим меньший ток в deep_sleep у ESP32. Педали и навешивание аналоговых костылей - это как раз по вашей части.
     
    Последнее редактирование: 10 фев 2018
  6. sharikov

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

    Сообщения:
    602
    Симпатии:
    52
    В режиме deep sleep esp32 не нужны никакие педали - все работает "из коробки" с током в слипе 5мкА причем и с кварцем 32768 в том числе. Кварц в rtc это хорошо потому что дает стабильность при длительных периодах засыпания.
     
  7. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    По измерению вам и привел, что вы сравнили исполнение while(1); на 166 МГц и waiti на 80 МГц :p
    Свинке без разницы... :p :)
    nikolz считает что это много и у него другие цифры в голове - он сравнивает с потреблением при CH_EN или с таймером от TI у ESP8266 отключающем питание. Схему он и =AK= представлял и заявляли о порядках менее 20 нА. :) В связи с этим и привожу ему, что ESP-32 в аналогичном режиме RESET=0 будет 0.4 мкА.

    Да и пока не вышло "5 мкА из коробки". Выходит сильно больше и приводил графики... Киньтесь примером для замера, а то вдруг что не так делаю или не учел...
    Полученный минимум пока в esp-idf/examples/system/ulp at master · espressif/esp-idf · GitHub и составляет 18 мкА (минимум на графике).
    Чип наверняка аналогичный вашему - Маркировка ESP32-DOWDQ6 и переключение провода +3.3В от измерителя на RTL8710BN при одинаковой функциональности в deep_sleep показывает 6 мкА.
    Короче не понятно что надо ESP-32 ещё вписать. И так уже коду на два файла у ESP-32, вместо строчки ex_sleep(маска просыпания по GPIO и таймеру, время в мс) у RTL. Тестов с внешним 32К ещё не делал на ESP и RTLB.
    Может надо опустить напряжение питания, как в заявке на ток в deep_sleep у ESP8266 в PDF?
     
    Последнее редактирование: 10 фев 2018
  8. =AK=

    =AK= Гуру

    Сообщения:
    1.231
    Симпатии:
    100
    В сущности это без разницы. Для некритичных применений и то и это достаточно мало, а для критичных - и то и это слишком много. Если и есть на свете применения, где эта разница играет какую-то роль, то лишь те, где были приняты ошибочные решения на ранних стадиях проектирования устройства. Вот pvvx уже давно носится с этими замерами как дурак с писаной торбой - значит, в его устройствах это критично, то есть, он принципиально облажался, когда выбирал их структуру. =:D=
     
  9. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Я ничего не строю на ESP-32.
    Последний раз про как выудить минимум была тема от вас с nikolz, так и не пришедшая к решению самими и поставленной задачи :)
    Там и была доказана ваша полная импотенция в электронике - решения не последовало и всё заброшено.
    Моё дело всего сравнить, а смысл использования при итого в "мало/много" - решать тому, кто собирается на этом что-то делать.
    По мере сравнения и изучения разных подходов найдется и оптимальный вариант.
    Вы играете в "Arduino", а я в тупые измерения. Каждому своя игра. :p
    Вот открыл доку по ESP-32 - там написано 5 мкА при deep_sleep. Хочу проверить... Исходить из вашей и nikolz представленной информации я не могу - она всегда ложна, приводится без доказательств и создана путем тыкания пальцем в небо...

    Справку про “критичность” для некоторых вариантов исполнения устройств, которые мне нужны, я вам уже давал. Могу повторить: Она заключается в том, что в пластиковом корпусе без вентиляции, рассеивание модулем более 1 Вт тепла критично для некоторых систем измерения, т.к. модуль является всего встраиваемой частью и остальное тоже выделяет тепло, да и внешняя рабочая температура должна удовлетворять пром. стандартам...
     
    Последнее редактирование: 11 фев 2018
  10. sharikov

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

    Сообщения:
    602
    Симпатии:
    52
    Пример использования чистого deep sleep в (сюрприз) examples/protocols/sntp
    Не забывайте про strapping pins они жрут ток и в примерах не конфигурируются. Проверяйте конфигурацию под ваш модуль. Для WROVER писал на первых страницах.
     
  11. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Пины все, кроме logUART висят на свободе...
    examples/protocols/sntp - попробую...
     
  12. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Программирование Flash и старт examples/protocols/sntp
    prog_start.gif
    Программирование модуля (заливка Flash) 30 секунд! + Время тупления макроса перед этим ещё пол минуты при никаких действиях :)

    В примере изменил только время deep_sleep на 61 секунду (а то за 10 секунд там не успокаиваются все в модуле :))
    Потребление с RESET:
    sntp_61sec_x100.gif
    Итог на режиме 10 мА Макс:
    sntp_61sec_ds.gif
    Нема реакции на кнопки и нет 5 мкА.
    @sharikov - Надо как-то выключить всё, включая таймер RTC и понизить питание до отключения LDO1.2В (обычно Espressif так дают параметры). Тогда может будет соответствовать заявкам на ток в 5 мкА в deep_sleep (там не указано, что что-то включено).
    В первых редакциях на ESP8266 было 10 мкА в deep_sleep. Потом поменяли на 20 мкА и приписали, что это при пониженном питании, когда Flash уже не работает. Так-же в документации значится 0.3 секунды соединения с AP :)

    PS: ESP-IDF это нечто – верх совершенства макросов сборки в 2018 году :) При смене COM порта для прошивки производится полная пересборка всего SDK в течении пары минут… Это дает понимание, почему его так долго отлаживают и отладить не могут :)

    ------
    Есть зависимость от температуры чипа. На 4-й раз измерения он почему-то со старта соединялся с AP 30 секунд. Нагрелся и остывал 2 минуты, после этого ток deep_sleep немого упал:
    sntp_61sec_500sec.gif
     
    Последнее редактирование: 11 фев 2018
  13. sharikov

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

    Сообщения:
    602
    Симпатии:
    52
    А нефиг прошивать на 115200 по дефолту. Поставьте скорость uart 921600 или выше станет быстрее.

    В примере sntp реакцию на кнопку никто не обещал. Там только задержка от rtc.

    Напишите make -j flash
    Автоматом параллельная сборка там не включается.

    Судя по графику у вас входы болтаются в воздухе вот и плавает.
    Кажлый раз повторяю что sprapping pins это поле с граблями.
     
  14. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    Вы сами просили всё по default.
    Можно и JTAG подключить.
    Ну и плохо. Значит не готов ESP-IDF для расчетной аудитории.
    В данном случае не сильно помогает.
    А пересброка всё равно, даже при -j 32 не достигает разумного времени.
    Это емкостная реакция, в цепях питания модуля. Так сразу не описать все причины возникновения такого выброса. При нагрузке измерителя резистором с коммутатором таких выбросов и плаваний нет. Только температурные, по характеристикам резистора.
    Пальчиком по выводам не меняет показания, если не тронуть питания или цепей связанных с ним.
    Сопротивление кожи и помеха от руки гораздо больше потребления в 6 мкА (при 3.3В это нагрузка в 550 кОм).
    Подключение щупа осла на 10 МОм для контроля питания больше влияет на смещение показаний.
    -------
    Уточнили бы, что вы имеете в виду под "sprapping pins это поле с граблями". При чем тут sprapping или strapping pins?

    По default все пины должны быть включены на ввод. При режимах sleep в зависимости от чипа обычно имеются специальные регистры настройки для пинов или применяется полное отключение GPIO контроллера. Ну висят на СМОП входах какие-то уровни. И что они вызовут? Генерацию на переходном уровне давно все победили. Помех у данного модуля при deep_sleep рядом нет – принимать на выводы нечего.

    Так что давайте излагайте – какая ещё беда с sprapping pins?
    -----
    Произвел доп. тест: прошел проводом GND при работающем deep_sleep по выводам GPIO - изменений нет.
    Замкнул на несколько GPIO, на которые при тыкании рукой были какие-либо наноамперные всплески:
    sntp_61sec_gpio_gnd.gif
    Изменений нет.
     
    Последнее редактирование: 11 фев 2018
  15. pvvx

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

    Сообщения:
    9.352
    Симпатии:
    1.320
    @sharikov - Согласно документации (Table 4: Strapping Pins на модуль ESP-WROOM-32 Datasheet) имеем такие Pull-Up/Down:
    PinsPulls.gif
    На самом деле имеем такую ситуацию:
    PinsGnd.gif
    Т.е. только GPIO14, GPIO15 и GPIO0 активны.
    Остальные пины при замыкании на GND (включая RX/TX, исключая EN/RESET) не вызывают никакой реакции (не отличить среди наноамперного шума).
    Получаем что ток Pull-Up 72..75 мкА (для Pull-Down аналогично) (примерный эквивалент 45 кОм), что говорит о том, что если есть какие замыкания, то они отразятся на уровне десятков мкА.
    Подключение к Pull-Up внешнего напряжения 3.3В не дает изменений, если напряжение немного меньше питающего модуль.

    Как общий итог - никаких проблем со Strapping Pins не наблюдается.

    PS: Жду пример как отрубить RTC таймер, чтобы получить заявку на 5 мкА :)
    Модули стандартные, как на всех фото Espressif, чипы в нутре стоят ESP32-DOWDQ6, 25Q32CS1G, этой детали:
    Снимок3.gif
    нет. Сэкономили (место под пайку есть - аналогичный модуль по разводке, так-же зеленой краской помечена Flash)
    Сдавать обратно Espressif как брак? :)
     
    Последнее редактирование: 11 фев 2018

Поделиться этой страницей