Энергопотребление ESP(итоги)

[pvvx]

Для получения минимального потребления с передачей нескольких значений в минуту или час по WiFi существует уже проверенное решение. Оно заключается в передаче одного стандартного пакета 802.11 или типа и приема его на другом оборудовании. Прием можно организовать и на ESP8266 используя только стандартные функции SDK и Arduino.

К примеру, среди стандартных функций, не ограничивая работу AP или STA, на ESP8266 есть функция оповещения приема пакета ‘Probe Request’. Логирование можно осуществить и на многих роутерах, установив OpenWRT.

Передача стандартного пакета ‘Probe Request’ занимает не более 1 мс (прием на СВЧ диоде около модуля):

Далее, на примере использования пакета ‘Probe Request’:

1. Включение модуля (аналогично после deep_sleep), загрузка программы и инициализация. На ESP8266 с использованием RapidLoader – 30..40 мс при 60..75 мА. На других модулях зависит от режима: из sleep - до 1 мс, из deep_sleep - порядок до 10 мс.
2. Модуль с датчиком, с самого первого старта, опрашивает датчик, упаковывает значение в MAC поле блока ‘Probe Request’. Время исполнения зависит от датчика. Возьмем опрос ADC, что составит 1 мс при 20 мА.
3. Включает тактирование и питание RF части, переписывает в её регистры записанные заранее значения и ждет инициализации RF части. Она аналоговая и требует время на это, как и на стабилизацию PLL. Данная процедура занимает пару мс при > 70 мА.
4. Включает передачу блока ‘Probe Request’. Время исполнения 1 мс при 150..200 мА.
5. Отключает RF и переводит чип в deep_sleep состояние. Если используется SPI Flash, то необходимо подать команду sleep и к ней. Время исполнения процедуры менее 1 мс при 25 мА.

В итоге:
Лог в UART на стороне модуля с датчиком:

...
ID:0x0018   ADC:0x0237
ID:0x0019   ADC:0x023c
ID:0x001a   ADC:0x0234
ID:0x001b   ADC:0x023c
ID:0x001c   ADC:0x023c
ID:0x001d   ADC:0x023c
ID:0x001e   ADC:0x023b
ID:0x001f   ADC:0x0237
ID:0x0020   ADC:0x023b
...

Лог в UART на стороне ESP8266 работающего к примеру с прошивкой "web-свалки":

...
WiFi event(7): Probe Request (MAC:02:00:37:02:18:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:3c:02:19:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:34:02:1a:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:3c:02:1b:00, RSSI:-48)
WiFi event(7): Probe Request (MAC:02:00:3c:02:1c:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:3c:02:1d:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:3b:02:1e:00, RSSI:-47)
WiFi event(7): Probe Request (MAC:02:00:37:02:1f:00, RSSI:-57)
WiFi event(7): Probe Request (MAC:02:00:3b:02:20:00, RSSI:-65)
...

Из этого получается, что время активности, когда модуль исполняет нужные нам действия составляет 4..5 мс, в которой среднее потребление около 110 мА из-за работающего RF. Самая большая и критичная часть – это загрузка. У всех ESP это самая долгая и потребляющая часть из имеющихся WiFi-SoC, которую удалось сократить всего до 30 мс и уменьшить стартовый ток в 2 раза используя RapidLoader. При этом это не всё время когда происходит потребление при старте, ему предшествует время старта генератора CLK на кварце…

На других WiFi-SoC старт из sleep происходит за 1 мс. Т.е. вся активность составляет до 6 мс, с средним потреблением 80..100 мА. А в режимах sleep с потреблением 0.1..3 мА у них активны все прерывания и остаются рабочими контроллеры, такие как UART, ADC, ... Что позволяет осуществлять передачу значений по мере их поступления с датчиков, с задержкой не более 5 мс от события.

 

[pvvx]

@nikolz - не знаю, что там у вас выходит, но на RTL8710BN получается примерно такой график зависимости потреления от времени между посылкой значений от ADC:

Для DeepSleep (перезагрузка):

• Потребление в активном режиме 100 мА
• Время активного режима 0,016 сек
• Потребление в sleep 0,0065 мА

Для Sleep (без перезагрузки):

• Потребление в активном режиме 100 мА
• Время активного режима 0,006 сек
• Потребление в sleep 0,185 мА

Если вы реализуете описанное CNLohr то в пределе, получите:

А сейчас у вас в сотни раз хуже. (Не забудьте, что шкалы на графиках логарифмические.)

 

[Evgeny D]

ESP-1F QIO L4 .
system_deep_sleep_instant(Time1*1000);
system_deep_sleep(Time1*1000);
ток в deep-sleep не более 18 мка (замерил сейчас специально для Вас)

У меня тоже 18.8 оказывается! На макетке к 3.3 была подсоединена только что купленная Attiny85... тремя выводами. Кушала 500мкА.

Спасибо за помощь!

 

[pvvx]

Благодарю за инфу. Я посмотрю.
--------------------------------------------------
Относительно поделок г-на CNLohr, то я видел его сообщение
How Low Can an ESP8266 Go?
----------------------------
я не сторонник такого подхода.
Если Вы заметили то я использую исключительно стандартный SDK любой верссии и ничего не переделываю.
А тем более против ковыряния в софте роутера. Мне такие решения не интересны.
Возможно решение без таких ковыряний на стандартном SDK, возможно разработчики когда-нибудь добавят необходимую функцию в SDK (всего надо одну).Будем ждать.
-----------------------------------------------------------------------------
Относительно RTL.
Пока изучаю RTL8710AF.
8710BN пока не заказывал, подожду еще немного.
---------------------------
Относительно Вашего утверждения про "в сто раз хуже"
Если приведете расчет энергозатрат на один сеанс активности при передачи пакета
или картинку как в начале темы,
то можно было бы посчитать. А пока это фейк.

Вот замер на WebRtl INA219 решения от CNLohr на моей сборке SDK к ESP8266 (его код доступен на github):

Среднее за 100..105 мс активности 35 мА (3.21..3.25В), deep_sleep 10000 мс при 23 мкА.
Замер на моей макетке в 100 сеансов (10 сек цикл) дает Average 0.00036 A при 3.30В (без провалов), deep_sleep у испытуемого модуля ESP-12E взятого из коробки новым: 23..24 мкА (зависит от температуры!).

Полное соответствие с графиком при параметрах:
Потребление в активном режиме 35 мА
Время активного режима 0,1 сек
Потребление в sleep 0,023 мА

Про фейки расскажите себе. Уж насмотрелись их от вас.
И так-же ничего нестандартного я в RTL не использую, включая и прием лога, который происходит на ESP8266 со стандартным SDK. Я просто не люблю быть первым - оставляю молодым - им отвечать я не мне Пришлось ждать 2 года...
Про Tplink и прочее - обращайтесь к CNLohr. Может ему нравится другой WiFi пакет для передачи данных...
И заметьте - старт с нуля тоже 100 мс 35 мА у него, не ваши 5..10 сек + полчаса времени настройки пользователем

 

[pvvx]

И очень интересует что не стандартного в ‘linux wireless extensions’ Version : 22 16.3.07 ?
Что оно не поддерживается в ESP? На Андроиде есть.
И что вы называете стандартным SDK? Arduino? Вот в ней нет никаких стандартных общепринятых методов работы с устройствами WiFi и изучать Arduino не имеет никакого смыслу.

 

[nikolz]

Вот замер на WebRtl INA219 решения от CNLohr на моей сборке SDK к ESP8266 (его код доступен на github):
Посмотреть вложение 5850
Среднее за 100..105 мс активности 35 мА (3.21..3.25В), deep_sleep 10000 мс при 23 мкА.
Замер на моей макетке в 100 сеансов (10 сек цикл) дает Average 0.00036 A при 3.30В (без провалов), deep_sleep у испытуемого модуля ESP-12E взятого из коробки новым: 23..24 мкА (зависит от температуры!).

Полное соответствие с графиком при параметрах:
Потребление в активном режиме 35 мА
Время активного режима 0,1 сек
Потребление в sleep 0,023 мА
Посмотреть вложение 5851
Про фейки расскажите себе. Уж насмотрелись их от вас.
И так-же ничего нестандартного я в RTL не использую, включая и прием лога, который происходит на ESP8266 со стандартным SDK. Я просто не люблю быть первым - оставляю молодым - им отвечать я не мне Пришлось ждать 2 года...
Про Tplink и прочее - обращайтесь к CNLohr. Может ему нравится другой WiFi пакет для передачи данных...
И заметьте - старт с нуля тоже 100 мс 35 мА у него, не ваши 5..10 сек + полчаса времени настройки пользователем

--------------------------------------
Где Вы у меня видели "5..10 сек + полчаса времени настройки пользователем"
Может перестанете херню всякую трындеть про других, а будете лишь про себя писать?
А то какой-то старческий маразм у вас наблюдается.
Вы либо давайте мои цитаты, либо прямо указывайте, что это Ваш бред, который Вы приписываете мне.
--------------------------------------
И зачем вы рисуете среднее на 10 секунд.
Приведите данные для одного активного режима.
Вы уже написали что в deep-sleep 23 мка.
-------------------------------
И не надо сюда еще сваливать RTL. У CNLohr на ESP8266 и плюс костыли к роутеру.
При этом страт за 120 мс никуда не исчезает.
Тогда и основной режим работы в 180 мс тоже никуда не исчезает (посмотрите его осциллограммы)
Т е речь идет лишь о том, полезете Вы в первый импульс передатчика, либо в нормальную посылку UDP.
Разница в потреблении будет не существенная.
Если желаете действительно сравнить результаты, а не хвалить свое и гадить на других, то приведите один активный цикл ESP подробно как у меня в начале темы.
Я вам это уже не один раз предлагал.

 

[pvvx]

--------------------------------------
Где Вы у меня видели "5..10 сек + полчаса времени настройки пользователем"
Может перестанете херню всякую трындеть про других, а будете лишь про себя писать?

А как ваш вариант настраивается на Роутер?

А то какой-то старческий маразм у вас наблюдается.
Вы либо давайте мои цитаты, либо прямо указывайте, что это Ваш бред, который Вы приписываете мне.

Даю ваш цитаты:

И зачем вы рисуете среднее на 10 секунд.

Где вы такое увидели?
https://esp8266.ru/forum/attachments/snimok5-gif.5851/
Это график зависимости потребления от времени между посылками (времени цикла просыпания - передачи - засыпания - ожидания в deep_sleep). Об этом описано ранее, в предыдущем сообщении.
Я понимаю, что у вас тяжело с графиками и математикой, вы это вчера уже демонстрировали на решении линейного уравнения...

Приведите данные для одного активного режима.

Приведены полностью с графиками. Тыц
Дубль-ссылка:

B точке измерения (передача пакета): 195.4 мА 3.21В.

Вы уже написали что в deep-sleep 23 мка.

В доке Espressif значится 20 мкА. Пока ни один модуль не смог столько показать при 3.3В питании.

И не надо сюда еще сваливать RTL. У CNLohr на ESP8266 и плюс костыли к роутеру.

Замеры даны на ESP8266, программа взята у CNLohr путем скачивания, трансляции и заливки в ESP8266. Изменений не производилось, кроме номера COM порта для заливки.
Мой описанный вариант с RTL и ESP8266 работают без костылей к роутеру.
Так-же пашет на Андроиде.

При этом страт за 120 мс никуда не исчезает.

Старт на графике виден и соответствует заяве в RapidLoader, который линкуется по умолчанию в мой MinSDK для ESP8266, который и использует Автор.

Тогда и основной режим работы в 180 мс тоже никуда не исчезает (посмотрите его осциллограммы)

Кто это такой?
В доке Espressif написано 2 мс. Реальные больше.

Т е речь идет лишь о том, полезете Вы в первый импульс передатчика, либо в нормальную посылку UDP.

Там сами передаем всего один пакет WiFi. Больше для передачи данных не требуется. Резерв у CNLohr куда работать есть - 20 мс лишних включен приемник RF до включения deep_sleep, + 20 мс лишних на калибровку RC генератора RTC, + не отключены опцией в mSDK сообщения, на которые уходит ещё к 10 мс. Вот с такими недоделками и замерено.

Разница в потреблении будет не существенная.

В десятки раз. Пробуйте с просыпанием через час и со стартовым циклом от включения питания. Т.е. в реале, а не в синтетическом тесте с подтасовкой результатов.

Если желаете действительно сравнить результаты, а не хвалить свое и гадить на других, то приведите один активный цикл ESP подробно как у меня в начале темы.

Он приведен.

Я вам это уже не один раз предлагал.

Но вы слепы или больны.
Или прикидываетесь ничего не понимающим дурачком, т.к. ваше решение в сотни раз хуже.
По этому и гадите?
Расписать до журнала мурзилки с картинками для безграмотных?
Вам broadcast пакет послать по WiFi?

 

[nikolz]

pvvx,
я вам скажу по секрету, что у вас неправильно написана прога deep-sleep.
Поэтому и ток 23 мка.
Возьмите deep-sleep из SDK и получите ток 18 мка.

 

[=AK=]

CNLohr делает измерения так редко, что короткие импульсы вполне могли оказаться не на графике.

 

[pvvx]

pvvx,
я вам скажу по секрету, что у вас неправильно написана прога deep-sleep.
Поэтому и ток 23 мка.
Возьмите deep-sleep из SDK и получите ток 18 мка.

Я измерял из SDK deep-sleep и из Arduino. Разницы нет, что 3 года назад, что сегодня.
И измерял не китайским тестером у которого на режиме измерения в мкА сопротивление шунта более 500 Ом на котом падает напряжение и модуль неверно стартует и криво работает.
В доках написано типовое 20 мкА при менее 2.5В на чип, а не на модуль. Espressif всегда врет.
На большинство Flash написано 1..5 мкА в Power-down Current ICC2 /CS = VCC, VIN = GND or VCC.
20+5 = 25.
Хорошо хотя бы что исправили в том году доки с 10 мкА при 3.3В, на 20 при 2.5 В Завтра ещё поправят...

Поменял правильно опции mSDK и программу CNLohr - пока вышло его произведение так:

Цикл активности стал уже 83 мс. Ещё дырка есть в 20 мс - тоже надо грохнуть...
Данный график с INA219, а она быстрее 963.3 замера в сек не умеет при 12 битах...
Осел включать лень.

Дальше оптимизировать не буду. Нафиг это всё надо на ESP8266 - там всё равно загрузку и старт SDK не исправить, как и кривые дрова WiFi не отлепить от LwIP и прочей ненужной шняги, но так любимой Espressif c её гулюко чипом с сотнями аппаратных ошибок
Та и дрова ESP не передают любые блоки в WiFi. Там тоже какая-то фигня кривая встроена... Копайтесь сами
------
Замер тока на ESP8266 с опциями 3 сек deep_sleep:

Измерялось этим:
https://esp8266.ru/forum/attachments/20180225_123421-jpg.5874/

 

[nikolz]

На сегодня получил следующие показатели работы ESP по WIFI UDP.
Время активности 265 мс затраты энергии 0.05 Дж.

Работать с датчиками можно и в загрузчике и в основной программе. При этом потребляемый ток 12 ма.

-----------------------------
И все это без каких либо ковыряний в SDK и софте роутера.

 

[nikolz]

Режим deep_sleep у ESP8266 единственный и не имеет модификаций. Т.е. от типов вызова процедуры не зависит - в данном режиме процессор и все GPIO отключены, кроме GPIO16.
0.5 мА - это 6.6 кОм в питание 3.3В.
У вас или где-то стоит постоянно подключенный примерно такой резистор или измеряете ток вместе со стабилизатором 5->3.3В.
20 мкА потребления у модуля Espressif предполагает в случае, если к модулю подводится только питание менее 2.5В (и по умолчанию при +25 С) и на нем правильно установлены подтягивающие резисторы, а не в случае когда подключены TX и RX и прочие сигналы и температура не +25С. Модуль может запросто питаться от этих внешних сигналов и может показать и отрицательный ток потребления по шине питания. Как у nikolz < 18 мкА

https://www.espressif.com/sites/default/files/documentation/0a-esp8266ex_datasheet_en.pdf
Страница 18, дополнение 3. И это замер только чипа ESP8266, без Flash и прочих элементов.
В документации до 2016.11 V5.1 значилось 10 мкА, но это не выполнилось, как и многое другое. Ещё не всё исправлено и в текущей версии документации.

Поясняю еще раз для дебилов.
Беремdeep-sleep которую сварганил pvvx и ставим ее в прогамму. измеряем ток в deep-sleep получаем 22 мка как и рассказывает pvvx.
А теперь вызываем эту программу из SDK и измеряем ток. получаем 18 мка.
Еще раз для дебилов медленно.
Ничего в железе не меняем лишь выкидываем дерьмо от pvvx и ставим из SDK получаем 18 мка вместо заявленных pvvx 22 мка.
pvvx, вам все понятно?

 

[nikolz]

Я измерял из SDK deep-sleep и из Arduino. Разницы нет, что 3 года назад, что сегодня.
И измерял не китайским тестером у которого на режиме измерения в мкА сопротивление шунта более 500 Ом на котом падает напряжение и модуль неверно стартует и криво работает.
Хорошо хотя бы что исправили в том году доки с 10 мкА при 3.3В, на 20 при 2.5 В Завтра ещё поправят...
Поменял правильно опции mSDK и программу CNLohr - пока вышло его произведение так:
Цикл активности стал уже 83 мс. Ещё дырка есть в 20 мс - тоже надо грохнуть...
Данный график с INA219, а она быстрее 963.3 замера в сек не умеет при 12 битах...
Осел включать лень.

Уверен, что Вы найдете оправдания очередным своим глюкам.
Но все же объясняю Вам следующее:
Берем Ваш пакет MinEspSDKLib и ставим в нем вашу deep-sleep
вот так:
void ICACHE_FLASH_ATTR user_init(void) {
ets_printf("test\n");
system_deep_sleep(1000000);
}
И измеряем ток получаем такую картинку: (Т е масштаб этой картинки соответствует масштабу всем моим картинкам)


Теперь следите внимательно за моими объяснениями, а то опять не поймете.
1) Вы утверждали что у Вас время старта 30 мс и кивали на вывод сообщения при старте - типа оно во всем виновато.
А я утверждал что время старта не может быть меньше 80 мс и это сообщение влияет мало.
Смотрим на Ваш результат - время старта 90 мс!!! где обещанные 30 или хотя бы 50 ?
Посмотрим на мой график



Время старта те же 90 мс.
Я в отличии от Вас ничего не оптимизировал и не создавал кучу софта, а использую все стандартное.
==================================

Теперь смотрим дальше.
На моем графике видно лучше первый импульс в 110 мс - это тот самый ответ в который CNLohr запихал свой ответ.
Поэтому длительность его варианта не менее 110 мс.
При этом замечу, что исходники библиотеки lwip теперь выложены в стандартном SDK.
================================
Поэтому вашей заслуги в решении CNLohr никакой.
А его решение не имеет практического значения, так как в этом решении нет возможности отодвинуть ответ для работы с датчиками.
Т е надо еще докавыривать Ваш оптимальный.
========================
И последнее:
В моем решении затраты энергии на сеанс связи 0.05 дж.
Вариант CNLohr по моим прикидкам затрачивает 0.015 дж.
т е выигрыш в три раза.
Но остается проблема с током потребления в основной программе при работе с датчиками и необходимость ковыряния в софте роутера.
=======================
У WIFI UDP ESP есть еще резерв - это интервал от 120 до 240 мс а также режим ESP-NOW.
================================
В итоге pvvx лишь продекларировал 30 мс старта, а CNLohr ему поверил и пропиарил его вранье.

 

[pvvx]

В итоге pvvx лишь продекларировал 30 мс старта, а CNLohr ему поверил и пропиарил его вранье.

Для дебилов тот-же CNLohr привел графики и описал, что весь цикл у него до 100 мс на ПО, написанном более 2-х лет назад.
Вы же приводите 263 ms в одиночном и выбранном замере, спустя более 2-х лет
Что-то туго у вас с усвоением того, что сделано давно.
У вас впереди ещё освоение минимального цикла в 30 мс загрузки и выхода с включением deep_sleep, продемонстрированным 3 года назад с описанием что надо сделать для этого.

 

[nikolz]

Для дебилов тот-же CNLohr привел графики и описал, что весь цикл у него до 100 мс на ПО, написанном более 2-х лет назад.
Вы же приводите 263 ms в одиночном и выбранном замере, спустя более 2-х лет
Что-то туго у вас с усвоением того, что сделано давно.
У вас впереди ещё освоение минимального цикла в 30 мс загрузки и выхода с включением deep_sleep, продемонстрированным 3 года назад с описанием что надо сделать для этого.

1) Для дебилов я объяснял как получить ток deep-sleep 18 мка.
Но Вы так и не поняли почему у Вас в deep-sleep ток 23 мка.
2) Вы опять не поняли Я написал что у меня 263 мс а у CNLohr 110 мc.
3) У CNLohr время старта такое же ка у меня т.е не менее 80 мс и это можно сделать без Вашего repidloadera на основе rbood.
4) Если я правильно понял,
то CNLohr вставляет свой пакет в посылку калибровки RF,
но работать ESP с его шедевром не хочет.
-----------------------------------------
ets Jan 8 2013,rst cause:2, boot mode3,6)
load 0x40100000, len 108, room 16
tail 12
chksum 0x84
csum 0x84
Ѓўтк¬X«‰ьь
Error wifi_config! Clear.
с(µ$v-‰dмR§l кt‡-µСl`HЁ„µХ,µ—X8ct
т е опять вещь в себе и надо кывырять непонятно что. и так все ваши поделки сделаны.
---------------------------------------------
Ну и где здесь стандартная SDK?

 

[pvvx]

1) Для дебилов я объяснял как получить ток deep-sleep 18 мка.
Но Вы так и не поняли почему у Вас в deep-sleep ток 23 мка.

Для не умеющих измерять всё было разжЁвано: у вас тестер имеет внутренний шунт в 1 кОм при замере и просачивается питание по выводам RX/TX. Замеры делайте в SDK, а не в чем-то другом. Замеряйте модуль отдельно, с подключенными только питанием 3.3В.

2) Вы опять не поняли Я написал что у меня 263 мс а у CNLohr 110 мc.

Он уточнил - до 100 мс в тексте, в последней версии, которую вы смотрели

3) У CNLohr время старта такое же ка у меня т.е не менее 80 мс и это можно сделать без Вашего repidloadera на основе rbood.

Его надо модифицировать!? До аналога rapidloader-а. Есть ли в этом смысл - что от него останется - название?
(если разбираться полностью с rboot, то он нарушает опубликованную им лицензию, не приводя авторов использованных решений, исключая мои, т.к. они всегда даны без лицензий и с желаемым требованием не упоминать меня, что относиться и к вам. CNLohr такого не допускает...).
И время загрузки стандартного SDK у rapidloader не 80 мс, а в два раза меньше. Даже у первой версии (43.2 мс с сигнала RESET):

4) Если я правильно понял,
то CNLohr вставляет свой пакет в посылку калибровки RF,
но работать ESP с его шедевром не хочет.

Работает без проблем. И там тоже не его решение - он указал от куда его взял. Читайте внимательнее то, что вам дают.

т е опять вещь в себе и надо кывырять непонятно что. и так все ваши поделки сделаны.
---------------------------------------------
Ну и где здесь стандартная SDK?

А где она у вас, если вы к ней включаете сторонние компоненты и берете решения из rapidloader-а и прочих "первопроходцев", но так и не можете уже годы достигнуть желаемого или повторить уже достигнутые другими параметры?
И ещё раз: Мои поделки/проделки сделаны не для "телепузиков". Для этого есть "сфера обслуживания", например - вы (или igrr и прочие фанаты ESP). Вот ваша задача и является донести, подготовить, обернуть в касивую обертку чужие решения и положить в рот потребителям, да ублажать их. Или вы думаете чего я с вами вожусь?
Вы у нас тут на форуме, самый большой фанат ESP. Дурики типа =AK= и подобные, никогда не выкладывают никаких решений для других и подходят только для наполнения контекста и развлечений толпы… В итоге остаетесь вы один, но вас надо ещё научить выкладывать решения в правильной обертке для потребителей.

 

[nikolz]

Для не умеющих измерять всё было разжЁвано: у вас тестер имеет внутренний шунт в 1 кОм при замере и просачивается питание по выводам RX/TX. Замеры делайте в SDK, а не в чем-то другом. Замеряйте модуль отдельно, с подключенными только питанием 3.3В.

Вы внимательно читали?
повторяю в сотый раз
Схему измерения не меняем
Но если поставить вашу функцию deep-sleep то ,eltn 23 мка
а если из SDK то 18 мка
и не важно что и куда втекает и вытекает так как это не меняется
а заменяется лишь функция ( так называется программа )
Дошло?

 

[pvvx]

Вы внимательно читали?
повторяю в сотый раз
Схему измерения не меняем
Но если поставить вашу функцию deep-sleep то ,eltn 23 мка
а если из SDK то 18 мка
и не важно что и куда втекает и вытекает так как это не меняется
а заменяется лишь функция ( так называется программа )
Дошло?

Т.е. в стандартный SDK надо впихнуть функцию из моих проделок многолетней давности?
Я измерял стандартный SDK, без "прибамбасов" - о чем вы и писали.
Дошло?

Вы бы объяснили, с какой целью надо в стандартный SDK вставлять что-то, чтобы проверить на соответствие документации на него? Вот в документации и описано, что типичное 20 мкА при 2.5 В.

 

[nikolz]

И время загрузки стандартного SDK у rapidloader не 80 мс, а в два раза меньше. Даже у первой версии (43.2 мс с сигнала RESET):

на rboot если убрать лишнее все то же самое.

 

[pvvx]

на rboot если убрать лишнее все то же самое.

Что от него останется?
Длительная загрузка первого блока SDK и увеличение до его старта как раз на ваши 40 мс?
Он грузит в IRAM и SRAM (rodata) до 3-х блоков в общей совокупности от 25 килобайт с Flash в режиме SIO и при этом ещё тратит время на вывод сообщений об этой загрузке в logUART.
Т.е. он станет чисто лишним промежуточным звеном между стартом ROM и загрузкой SDK.
RapidLoader на загрузку блоков в 25 кило в IRAM тратит 3.3 мс в режиме QIO через аппаратный XIP.
В него не вставлено переключение на 80 МГц шины, т.к. иначе загружаемый стандартный SDK вообще балдит со скоростями UART. В свою сборку можете встроить переключение на 80 MHz, что ещё ускорит данную часть. Но дальнейшая структура уже не должна переключать PLL заново - на это требуется время. А т.к. переключение PLL находится в самом SDK, по этому его не вставлено в базовой версии, чтобы не получить двойную задержку на устаканивание PLL. Замер что быстрее - два раза переключать PLL на 80 MHz показал, что не стоит это того и не дает ускорения.