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

[=AK=]

КР544УД2 (их много и первыми нашел, а 140УД7 только в железном корпусе с позолотой...

Не, не катит, он нестабильный. Впрочем вам, как отпетому ламеру, простительно это не знать. С выводами цепи коррекции тоже, небось, нахимичили. Верните в схему то, что у вас раньше стояло, то ли 140УД7, то ли КР544УД1. ==

 

[pvvx]

Не, не катит, он нестабильный. Впрочем вам, как отпетому ламеру, простительно это не знать. С выводами цепи коррекции тоже, небось, нахимичили. Верните в схему то, что у вас раньше стояло, то ли 140УД7, то ли КР544УД1. ==

Но в моей версии работает и разницы практически нет.
Т.е. пишем так:
В тесте участвовали:

Вас это успокоило?
Или найти посвежее 820-й? Или более современную замену?
25 pA maximum input bias current меня устраивает для данной одноразовой бадьи

 

[A_D]

Глупая отмазка. Которое относится к "глупы и не шарят", а не ко "всем". Вы, оказывается, и с русским языком тоже не в ладах. ==

Хах. Только сейчас поняли, что профукались... и теперь свои нелады с пониманием слов перекладываете на другие плечи.

Я указал чип, в его даташите есть типовая схема применения. Гуглить тоже не умеете?

У меня цитата вашего прошлого сообщения, если опять не заметили... и текст к нему, а не к новому, к которому вы приплетаете цитату.

Схема pvvx мало того что ламерская, она изначально поганая, примерно 40-летней давности. С радиаторами, операционником 140УД7 и дарлингтоном на транзисторах МП39 и П213Б. И схема вытащена из помойки, и детали к ней pvvx поставил оттуда же. ==

Ну окей, да вот только вы ничего не даёте взамен, только и умеете хаить.. что как бы намекает. (уже не говорю, про то, что откуда вы там увидели МП* П*... с чтением букв да схем уже видно, что у вас есть определённые проблемы)

 

[sharikov]

Проверил пример ulp.
Нужно правильно конфигурировать rtc_pull up/down и strapping пины. Вообще rtc_gpio и sprapping пины в спячке похожи на поле с граблями и грабли до горизонта.
Результаты для тактирования от кварца 32768 и встроенного RC такие: (в обоих случаях время спячки ulp составляет 20ms)

XTAL_32K: Iavg=51uA T=119.16us t0=1.4us
INTRC_150K: Iavg=16uA T=34.33us t0=1.4us

Здесь:
Iavg - средний ток потребления
T - время активности ulp
t0 - время импульса от ulp на gpio

Ток потребления при зацикленной программе ulp:
Iulp_run=1.43mA
Он одинаковый для XTAL_32K и INTRC_150K.

    .text
    .global entry
entry:
    READ_RTC_REG(RTC_GPIO_OUT_REG, 13+14, 1)
        and r0, r0, 1
    jump out_h, eq
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TC_REG, 13+14, 1, 1)
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TS_REG, 13+14, 1, 1)
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TC_REG, 13+14, 1, 1)
    jump out_end
out_h:
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TS_REG, 13+14, 1, 1)
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TC_REG, 13+14, 1, 1)
    WRITE_RTC_REG(RTC_GPIO_OUT_W1TS_REG, 13+14, 1, 1)
out_end:
    jump entry

При работе от кварца 32768 потребление в разы выше по сравнению с RC_150K. Это происходит потому что ulp активен гораздо дольше, но скорость его работы такая же. Много времени теряется на старт и остановку ulp. Видимо есть какие-то таймауты или логика синхронизации ulp-rtc которые в случае кварца 32768 слишком велики. Можно ли это менять не выяснял.
Если время спячки ulp бесконечно ток потребления становится одинаковым для случаев XTAL_32K и INTRC_150K и оставляет 5uA.

 

[pvvx]

Ток потребления при зацикленной программе ulp:
Iulp_run=1.43mA
Он одинаковый для XTAL_32K и INTRC_150K.

Почему такой большой ток?
В доках заява на работающий ULP сопроцессор в 0.5 мА...

Если время спячки ulp бесконечно ток потребления становится одинаковым для случаев XTAL_32K и INTRC_150K и оставляет 5uA.

А сколько выходит когда на RESET подан "0"?

 

[sharikov]

Почему такой большой ток?
В доках заява на работающий ULP сопроцессор в 0.5 мА...

Ахз. Может потому что в тесте машет ногой gpio15.
Завтра проверю без ногодрыга.
C gpio15 в режиме выхода в ulp странно. Когда ulp активен gpio выдает установленное значение а когда ulp в спячке если gpio выдает "0" он остается активен а если "1" - переходит в Z cостояние. С другими gpio еще не проверял.

А сколько выходит когда на RESET подан "0"?

Менее 1мка (не регистрируется).

 

[sharikov]

Почему такой большой ток?
В доках заява на работающий ULP сопроцессор в 0.5 мА...

Проверил когда ногой не машет - потребление такое же: 1.43ma.

 

[pvvx]

Проверил когда ногой не машет - потребление такое же: 1.43ma.

Т.е. смысла в активном ULP нет... потребление сравнимо с основным CPU на заниженной частоте или sleep до прерывания, или в режимах DTIM у любого WiFi-SoC.

При работе от кварца 32768 потребление в разы выше по сравнению с RC_150K. Это происходит потому что ulp активен гораздо дольше, но скорость его работы такая же.

Там что, кварцевый генератор запускается и останавливается?
Тут что-то не понятно - сам сопроцессор жрет или активность его питаний?

Много времени теряется на старт и остановку ulp.

Если оно больше времени восстановления RTOS после sleep для обычного CPU, то нафиг оно нужно, это ULP?
Вот тут, правда на другом SoC пример https://esp8266.ru/forum/threads/is...ja-pitanija-v-rezhime-sleep-u-rtl8710bn.2936/

Вам нужно включить сохранение последнего состояния определенного выхода, прежде чем вы поместите чип в режим гибернации. Для этого используйте функцию `rtc_gpio_hold_en (gpio_num_t gpio_num)`.
Существует также функция `rtc_gpio_hold_dis (gpio_num_t gpio_num)`, чтобы отключить сохранение последнего состояния после того, как чип просыпается, и вам нужно изменить вывод.
Включение и отключение удержания контактов из ULP-программы несколько сложнее.
Вместо использования одной функции вам необходимо установить определенные биты в определенных регистрах,
которые зависят от номера / типа штыря.
есть таблица `rtc_gpio_desc`, где вы можете найти все контакты и бит RTC IO.
esp-idf/rtc_module.c at master · espressif/esp-idf · GitHub

Это надо совершить столько действий вместо простой остановки CPU на sleep в ожидании прерывания?
До 1 мА жрет работающий на полную катушку до пары МГц почти любой современый MCU. Тем более передача данных от ULP основному процу получается сравнимая "по накладным расходам", т.к. надо "поместить чип в режим гибернации"...
Отделите котлеты от мух – возьмите более реальные задачи под уровень чипа (у ESP-32 CLK CPU к 0.5 ГГц!).
Низкое потребление используется, когда опрашивается ПОСТОЯННО какой датчик (может и не один) со своим интерфейсом (SPI/I2C/UART/…) и накоплением данных, плюс осуществляется проверка (и управление) парочкой примитивных сигналов, по которым часто требуется быстрая реакция на сторону за WiFi.
Если в режиме малого потребления данных набирается мало – то WiFi отпадает и меняется на что-то типа BLE, где предельные пики потребления до 15 мА и всё упрощается.
Что-то не так в филармонии. Копать надо.

 

[sharikov]

Еще проверил пример с гитхаба
GitHub - krzychb/ulp-loop: Test of ESP32 reatining RTC IO outpus in hibenation mode
после доработки под плату WROVER и при слипе 20мс получается те же 16мка. Этот пример правильно машет ногами в слипе.

Т.е. смысла в активном ULP нет... потребление сравнимо с основным CPU на заниженной частоте или sleep до прерывания, или в режимах DTIM у любого WiFi-SoC.
Там что, кварцевый генератор запускается и останавливается?
Тут что-то не понятно - сам сопроцессор жрет или активность его питаний?

Кварцевый генератор 32768 работает непрерывно.
Запискается и останавливается встроенный генератор 8МГц для тактирования ulp и меняют напряжение питания RTC.
Вот активность питаний и жрет лишний ток.

Это надо совершить столько действий вместо простой остановки CPU на sleep в ожидании прерывания?

Токи утечки!!!
Идет манипуляция стабилизаторами питания и включение/выключений тактовых генераторов. Поэтому основной процессор просто на sleep поставть недостаточно для микропотребления.

ulp может быть интересен тем что он работает постоянно в том числе когда основной процессор активен.
Выделяем опрос датчиков в отдельную задачу в ulp запускаем и забываем про него навсегда. Когда надо основной процессор разбудят с уже готовым результатом измерений.

Если в режиме малого потребления данных набирается мало – то WiFi отпадает и меняется на что-то типа BLE, где предельные пики потребления до 15 мА и всё упрощается.
Что-то не так в филармонии. Копать надо.

да. потребление 5-15мка в слипе и 500+ма в работе меня ставят в тупик когда я думаю над источником питания. линейник для 500+ма сразу отпадает а у импульсного преобразователя приличное потребление на холостом ходу.

 

[pvvx]

Можете экспериментально подтвердить 500 ма в работе?

Включите номинальный CLK CPU в конфиге и будет и более...
А 'Шариков' просил сделать замеры на установках по умолчанию. При них ESP-32 принимает даже медленнее чем ESP8266. Но качество примера кода в примере из IDF теста на производительность не смотрел - может там вообще...(сплошной sleep/halt у CPU и на 80 МГц). И учтите что дал для сравнения замер приема TCP потока по WiFi, а не передачи.
Основной пик у ESP-32 был при старте и инициализации SDK с WiFi. Но его грохнули, путем "задавливания" CPU. Иначе у многих вообще не запускалось c питанием от USB...
Найдите тестовый код от Espressif - там всё и вылезет (и там трансфер поболее). Его ныне и попрятали.

Как я знаю 500ма - это рекомендация к выбору блока питания.
При этом никто не утверждает что это средний ток для источника питания.

В рекомендации 1A. Это у USB стандартное ограничение в 0.5A...

Всё это дело наживное – разберетесь сами.

Актуально другое – при автономном питании есть очень важный момент:

Момент включения питания (или возобновления). Тут никакие ULP не помогут, т.к. его ещё надо проинициализировать. На это требуется большой заряд от источника. А если его нет – устройство будет неработоспособно и возвернуто пользователем по гарантии, как нерабочее. Сам же модуль не может указать, что питание мало и его достаточно только для режима, в который он войти не может. Начнете опять огород разводить вокруг модуля - суперкапы и прочее (обязательный внешний BOR, т.к. внутренний не работает)....
По этому сразу произведите тест от CR2032. Если не запуститЬся - в помойку.

 

[pvvx]

Еще проверил пример с гитхаба
GitHub - krzychb/ulp-loop: Test of ESP32 reatining RTC IO outpus in hibenation mode
после доработки под плату WROVER и при слипе 20мс получается те же 16мка. Этот пример правильно машет ногами в слипе.

Ну вот - говорил же, что пример deep_sleep в IDF какой-то кривой. При RESET получаете меньше мкА, значит можно выжать что-то близкое к этому. Там тоже утечки всех выключателей...
А с сопроцессором дело такое - если бы было ядро на уровне хотя-бы Cortex M0 - то тогда да. А так...
Cortex M0 + Cortex R4 = Exynos i T200

да. потребление 5-15мка в слипе и 500+ма в работе меня ставят в тупик когда я думаю над источником питания. линейник для 500+ма сразу отпадает а у импульсного преобразователя приличное потребление на холостом ходу.

К слову, всё тот-же электролит на 1000 мкФ 16 В (новый, малого размера). Подключил к БП и зарядил на 10 В. Закоротил на пару секунд и подключил к ADC с 33 кОм входным сопротивлением (итого что на нем творилось в 1000 секунд):

(вроде написано конденсатор, а не аккумулятор )
И о каких мкА будет разговор, если собирать стабилизатор на 10мкА .. 1A для ESP-32 на простых деталях? Там утечек будет больше, а на дорогих - проще взять другой модуль

 

[pvvx]

Стоит флэшка Gigadevice c id=0x6016 (GD25LQ32?). холостое потребление у нее приличное: 50uA. И у psram небось столько же.

+ 1 мА специальным резистором:


От VDD_SDIO ESP-PSRAM32 и питается...
ESP32 Modules and Boards — ESP-IDF Programming Guide v3.0-dev-820-gb3fb5e2 documentation

ESP32-WROVER module (front and back)

• Datasheet (PDF)
• ESP-PSRAM32 Datasheet (PDF)

Полез заказать для коллекции что нового вышло из ESP-32 и наткнулся... Заодно выяснил, что никаких sleep с низким потреблением основного CPU для ESP32-WROVER не выйдет. Только если вырубить питание Flash и psRAM.
Про сборку сверху flash на кристалле ESP-32-PICO-D4 говорят как о эксперименте, сколько протянет flash в высокой температуре до потери памяти...
ESP-WROVER-KIT V3 на али нет.
Выходит, что заказывать, даже для тестов пока нечего.

 

[pvvx]

Еще проверил пример с гитхаба
GitHub - krzychb/ulp-loop: Test of ESP32 reatining RTC IO outpus in hibenation mode
после доработки под плату WROVER и при слипе 20мс получается те же 16мка. Этот пример правильно машет ногами в слипе.

Изменил кол-во циклов на [inline].set toggle_cycles_to_wakeup, 0b0011111111111111[/inline]

 

[pvvx]

Я понимаю, что Вы строго соблюдаете систему мер CИ, но может быть возможно вместо ампер на оси "Y" написать ма, а единицу измерения "А" вынести в заголовок а не писать около каждого числа?

А меня устраивает, что есть. Всё равно данные обрабатываю в другой программе, а это чисто монитор, да и предел стандартной шкалы 3A... Это тут козявки ковыряем Плюс ещё на этой-же панели несколько шкал для других графиков и каналов и всё в цвете. Я их отключаю чтобы сделать "скриншот", а то с ними ругались вообще, что ничего не понятно (но мне в самый раз)
------
Кто добился уже менее 10 мкА в deep_sleep c установленным временем до просыпания?
Модуль EMW3080:

И время загрузки после deep_sleep с инициализацией SDK с повторным входом почему-то сильно меньше...

 

[pvvx]

это все интересно чисто теоретически,
так как в реальном применении это не имеет смысла.
Важно не сколько потребляет, когда умер, а сколько потребляет когда жив.
ESP8266 можно усыплять и просыплять через EN и получим не более 10 мка.
Без каких либо выкрутасов, за копейки, и с очень простым софтом (это я так для примера).
А тут столько напряга, придумок, фокусов, доставания кролика из шляпы.

Вы наверно перепутали что-то. У ESP-32 и прочих модулей ничего внешнего не надо для deep_sleep с таймером + прерывания по пинам + будильник (RTC - заданное время) + ещё разное в зависимости от чипа.
Какой напряг к примеру у RTL при вставке команды в программу по типу sleep(биты кто побуждает, время сна)?
Есть заморочки только в том, что самих типов sleep пачка Но там не сложно разобраться, т.к. в основе обычно всего 3 режима:
Deep_sleep - это когда совсем всё вырублено (остается минимум - GPIO + НЧ таймер/RTC) и требует перезагруки ( 1..10 мкА)
Промежуточный тип (каждый называет по разному) где типа активно всякое доп.оборудование, типа пробуждающего при поступлении адреса устройства на I2C, или UART, ... Жрет при этом больше, но тоже нужен перезагруз. (10..200 мкА)
И sleep - когда основной проц ждет прерывания от своих контролеров и никаких перезагрузок не надо ( 100..200 мкА).
И у нас пока бяда с обоими крайними типами у ESP-32...
А у вас глупые желания низкого потребления у производительного CPU с FPU - пусть вечно спит, а когда надо - выстрелит на все свои сотни MГц/ГГц. Ногами (GPIO) ему шевелить не надо. Пошевелите ESP8266 на USB2.0
Всё работает по DMA - процу надо быстро коммутировать каналы DMA и обрабатывать потоки в них. Всё это происходит по прерываниям, а между ними - пусть спит. С DMA у ESp-32 тоже не всё Ок...

 

[sharikov]

Полез заказать для коллекции что нового вышло из ESP-32 и наткнулся... Заодно выяснил, что никаких sleep с низким потреблением основного CPU для ESP32-WROVER не выйдет. Только если вырубить питание Flash и psRAM.

Там встроенный стабилизатор и рубит. Заметной утечки у него нет. Резистор на 1.8V стоит чтобы разряжать емкость иначе при следующих включениях флэшка зависнет.

Про сборку сверху flash на кристалле ESP-32-PICO-D4 говорят как о эксперименте, сколько протянет flash в высокой температуре до потери памяти...

На 80MHz проблемы перегрева нет и на 160 греется но жить можно. Нефиг гонять процессор на предельной частоте. Вообще 240MHz dualcore это чисто рекламная фишка и на практике не применима из-за неразумного потребления. Ну не умеют китайцы создавать сбалансированные архитектуры. Не только espressif не умеет это такая национальная особенность. Где нет западных церберов китайская фантазия создает "ужас летящий на крыльях ночи".

ESP-WROVER-KIT V3 на али нет.
Выходит, что заказывать, даже для тестов пока нечего.

тут есть весь ассортимент esp32 включая чипы.
ESP-WROVER-KIT - ElectroDragon
Я кит не заказывал. Его придется курочить да и jtag на ft2232 мне как то без надобности.
Али похоже сдувается: цены стали загибать уже и не ebay можно дешевле купить или в других местах.

 

[sharikov]

Можете экспериментально подтвердить 500 ма в работе?
По измерениям pvvx импульсный ток при передаче по WIFI не более 220 ма (у ESP8266 доходило до 300)
Как я знаю 500ма - это рекомендация к выбору блока питания.
При этом никто не утверждает что это средний ток для источника питания.

Измерения на примере iperf .
Частота 240MHz два ядра wifi +20dbm
I_idle_sta_connected =0.12A

iperf (tcp client):
bandwidth = 21.55 Mbits/sec
Iavg=0.24A
I=0.15A/0.475A (min/max)


ping:
Ipk=0.48A t=45us

SDK init:
Ipk=0.55A t=~5ms

 

[pvvx]

Можете измерить минимальное время просыпания передачи пакета по WIFI (UDP) или BLE и засыпания. При этом выделить временные интервалы различных состояний.
Спасибо

"Минимальное время просыпания передачи пакета по WIFI (UDP)": соединение к AP, получение IP по DHCP на разных роутерах от 0.7 до 5 сек.

 

[pvvx]

Измерения на примере iperf .
Частота 240MHz два ядра wifi +20dbm
I_idle_sta_connected =0.12A

iperf (tcp client):
bandwidth = 21.55 Mbits/sec

21.55/8 = 2.69375 Мегабайт в сек полезных данных или это о том, что PHY на 150 Mbits/sec?

SDK init:
Ipk=0.55A t=~5ms

571 мА -> https://esp8266.ru/forum/threads/esp32devkit-v1.2062/#post-29740

 

[sharikov]

Можете измерить минимальное время просыпания передачи пакета по WIFI (UDP) или BLE и засыпания. При этом выделить временные интервалы различных состояний.

Измерил время активности основного процессора в примере ulp-loop. Пример этот wifi не включает он только дергает ногой и сразу же засыпает.
Наблюдается 2 фазы T1 и T2 (загрузчик и sdk)
T1=28.3ms I1=0.19A
T2=75ms I2=0.36A
при этом app_main судя по выводу в uart начинает работать где-то на T1+72ms а что делает sdk 72ms неведомо.
При частоте процессора 80MHz цифры те же.

Измерил пиковый ток при инициализации wifi
240MHz: Ipk=0.55A t=~5ms
80MHz: Ipk=0.5A t=~6.5ms

По моему дальше измерять потребление бессмысленно.
Ясно что с разумными затратами батарейное устройство на ESP32 не сделать.
Для работы нужно ориентироваться минимум на 500мА источник (это только еспшке без учета дополнительных потребителей).