ESP8266. Сверхмалое потребление

nikolz · 27 Мар 2018

Добрый день,
Выкладываю предварительные результаты моего варианта уменьшения потребления eSP в режиме WIFI.
В чем отличие от известных.
Решение создается на основе стандартного SDK и модифицированного мною загрузчика rboot.
Вот такая картинка получается:

алгоритм работы ESP - стартует, посылает данные по WIFI и ложится спать.
Фрейм любой . Можно чередовать с фреймом UDP или TCP .
-----------------------
старт:
время 104.6 ms;
энергия сеанса 3.6 ma*s или 0.012 J(Дж) для Vc=3.3 в;
основная программа WIFI:
время 14.6 ms; энергия сеанса 1.24 ma*s или 0.004 J(Дж);
------------------------
Итого на один сеанс связи:
время 119.2 ms; энергия сеанса 4.84 ma*s или 0.016 J(Дж).
------------------
75% энергии затрачивается на старт ESP8266.
Хорошо бы эту энергию да в мирных целях.
--------------------
Есть какие-нибудь идеи, как это сделать?

nikolz · 27 Мар 2018

это результат одного из способов снижения потребления во время старта.
Суть его сводится к снижению напряжения питания во время старта до 2.5 вольт.
При этом потребление ESP уменьшается в два раза (см ранее старт 0.012 дж).

Удобно использовать если нет надобности во включении WIFI, например при работе с датчиками в nboot.
-----------------------------
При работе с WiFi общее потребление ESP снижается в 1.5 раза до 0.01 J(Дж) на сеанс активности с WIFI.
-----------------------

pvvx · 5 Апр 2018

INA219

воткнутая в STlink с STM32F103C8.
ESP-12E, прошивка выкладывалась... Никаких доп. ненужных boot.
Вскоре 24 бита > 250 ksps (как закончу модернизацию своего лаб. БП)

nikolz · 5 Апр 2018

pvvx написал(а):
Посмотреть вложение 6151 Посмотреть вложение 6150 Посмотреть вложение 6149
Посмотреть вложение 6152
INA219 воткнутая в STlink с STM32F103C8.
ESP-12E, прошивка выкладывалась... Никаких доп. ненужных boot.
Вскоре 24 бита > 250 ksps (как закончу модернизацию своего лаб. БП)

Т е у Вас нет никакого кода в ESP?
-----------------------------------------------------------
60 ms, похоже на правду.
У меня 72..82 mc( там где ток становится меньше 30 ма) из них 60 мс - это исполнения кода из ROM и 12..20 мс nboot.
Т е разница у Вас на время исполнения nboot в 12..20 ms .
В стандартном загрузчике - это 120 мс.
Поэтому мой вывод что область загрузки не менее 80 мс.
у вас получилось не менее 60 мс, но не 30 мс, как Вы утверждали ранее.
-----------------------------
ну согласитесь что 60, а не 30.
--------------------------------------------------------
про терминологию.
Если есть хотя бы одна команда , то это я и называю boot.
---------------------------------
На графике нет исполнения кода для перехода в deep-sleep?
Если есть то это и будет boot.
-------------------------------------------------
Т е boot - это код, который исполняется до запуска основной программы и
в конечном счете исполняет, либо код deep-sleep, либо старт основной программы.
---------------------------------------------------
Возможно Вы этот отрезок кода называете иначе.
--------------------------------------
Если Вас смущает отличие вида графиков, то поясняю еще раз.
-----------------------------------------------------------------------
у меня в графиках используется сжатие без потери экстремумов и сжатие при флюктуации данных в пределах 0.2 ма.
это позволяет видеть все существенные изменения и отображать графики с миллионами не меняющихся значений.
мне так удобнее обрабатывать большие массивы данных.
-------------------------------------------
Т е если данные в виде ступеньки,
то на графике будет всего 4 точки даже,
если график содержит миллион отсчетов.

nikolz · 5 Апр 2018

Нет особой разницы будет это 60 или 80.
Так как далее при работе с датчиками ток потребления в 2-3 раза меньше по сравнению со стартом и в 4-5 раза меньше по сравнению с включенным wifi. Т е выигрыш в 20- 30 мс составит примерно 0.002 Дж на активный режим.
Это практически ноль по сравнению с потерями при работе WIFI. как минимум 150 мс с током не менее 70 ма.
------------------------
Поэтому существенное уменьшение потребления можно получить лишь уменьшив этот интервал, но сохранив протокол UDP или TCP и еще добавив протокол WDS.
Вот это интересная задача.
Можете предложить решение?
Спасибо

pvvx · 5 Апр 2018

nikolz написал(а):
Нет особой разницы будет это 60 или 80.
Так как далее при работе с датчиками ток потребления в 2-3 раза меньше по сравнению со стартом и в 4-5 раза меньше по сравнению с включенным wifi. Т е выигрыш в 20- 30 мс составит примерно 0.002 Дж на активный режим.
Это практически ноль по сравнению с потерями при работе WIFI. как минимум 150 мс с током не менее 70 ма.
------------------------
Поэтому существенное уменьшение потребления можно получить лишь уменьшив этот интервал, но сохранив протокол UDP или TCP и еще добавив протокол WDS.
Вот это интересная задача.
Можете предложить решение?
Спасибо

Очередные ошибки.
Вам необходимо привести диаграмму с недо-бут и стандартной SDK? Платите за такие испытания, т.к. интереса это не представляет - заранее известно, что выйдет за 200 мс даже без включения WiFi. В Arduino и более.
Только применение хаков, указанных в rapid-loader, meSDK, SDK no WiFi, более 2-х лет назад позволит сократить это время на 100 с лишним м.секунд.
А применение нестандартного типа загрузки позволяет сократить старт и время выполнения кода входа в deep_sleep, до 35 мс. Это пока предел для ESP8266, продемонстрированный более 3-х лет назад... Для него требуется внешний "костыль", желательно в виде MCU, а не россыпи ТТЛ логики

Ну и т.к. вешается внешний костыль, то нафиг вообще deep_sleep и прочее от ESP8266.

nikolz · 5 Апр 2018

pvvx написал(а):
Очередные ошибки.
Вам необходимо привести диаграмму с недо-бут и стандартной SDK? Платите за такие испытания, т.к. интереса это не представляет - заранее известно, что выйдет за 200 мс даже без включения WiFi. В Arduino и более.
Только применение хаков, указанных в rapid-loader, meSDK, SDK no WiFi, более 2-х лет назад позволит сократить это время на 100 с лишним м.секунд.

Т е вы признаете что не 30 а 60 а с кодом и все 80?
А про rapid-loader это Вы опять придумываете.
Уже сто раз это обсуждали.
У Вас в него нельзя ничего вставить так как надо пересчитывать адрес (Сами так мне объяснили)
И именно отличие его от rboot в том и состоит что rboot можно залить с нуля и все.
Плата за это 10 мс и все.
-------------------
относительно meSDK там вообще ничего существенного нет.
SDK no WiFi не дает выигрыша против работы в загрузчике.
Да Вы сделали эти свалки давно, но они так и не пригодились.
Все это легко реализуется на стандартном SDK с потерей 10-20 мс при старте. но без недокументированных свалок.
--------------------
Поэтому не надо ля ля.
Где же обещанные 30 мс или как вы недавно написали даже 3 мс?
Их нет у вас. А признать свою ошибку Вам апломб не позволяет.
-------------------------
И замечу не я в Ваши тему влез с попыткой оправдать измерения двух-летней давности, а Вы
И Вы доказали, что 2 года назад Вы ошиблись Поэтому исправьте в вашей свалке 30 мс на 60 хотя бы.

pvvx · 5 Апр 2018

nikolz написал(а):
Т е вы признаете что не 30 а 60 а с кодом и все 80?
А про rapid-loader это Вы опять придумываете.
Уже сто раз это обсуждали.
У Вас в него нельзя ничего вставить так как надо пересчитывать адрес (Сами так мне объяснили)
И именно отличие его от rboot в том и состоит что rboot можно залить с нуля и все.
Плата за это 10 мс и все.
-------------------
относительно meSDK там вообще ничего существенного нет.
SDK no WiFi не дает выигрыша против работы в загрузчике.
Да Вы сделали эти свалки давно, но они так и не пригодились.
Все это легко реализуется на стандартном SDK с потерей 10-20 мс при старте. но без недокументированных свалок.
--------------------
Поэтому не надо ля ля.
Где же обещанные 30 мс или как вы недавно написали даже 3 мс?
Их нет у вас. А признать свою ошибку Вам апломб не позволяет.
-------------------------
И замечу не я в Ваши тему влез с попыткой оправдать измерения двух-летней давности, а Вы
И Вы доказали, что 2 года назад Вы ошиблись Поэтому исправьте в вашей свалке 30 мс на 60 хотя бы.

Нет, опять не так.
~35 мс - это старт ESP до исполнения любого кода при стандартном типе загрузке "Flash". Примерно, по причине разницы времени старта кварца у разных модулей. Разброс параметров.
Выход в deep_sleep у SDK выполняется более 100 мс.
Чтобы запустился SDK требуется полная его загрузка и инициализация, что есть ещё более 100 мс, в случае отключенного WiFi.

Прикручивание rapid-loader к снятой на диаграмме прошивке не дает ничего = +- 2 мс.
Прикручивание недо-boot = + 60 мс и двойное потребление (к 70 мА)

Только калибровка RC генератора RTC с тактом в 6 мс у SDK занимает дцать мс... Это время надо прибавить к времени таймера выхода в deep_sleep, устанавливаемого в SDK на 100 мс. До этого SDK ещё проверяет режимы WiFi и отключает WiFi (с закрытием соединений у LwIP), на что уходит иногда и более 20 мс, т.к. идет запись в Flash со стиранием сектора...
100 мс программный таймер запускается в надежде, что за это время соединения LwIP закроются и исполняться другие отложенные 'кал-баки' дров WiFi висящие на программных таймерах. Espressif беспокоится за вас при включении deep_sleep - делает всё, на случай если вы что-то забыли

Ну и конечный код в IRAM, выхода в deep_sleep, отрабатывающий по окончанию 100 мс таймера, выполняется за время x * 2..5 (т.к. он имеет в два раза больше обращений к медленным шинам + время на ожидание передачи команды "sleep" для Flash) относительно кода, к которому и приведена диаграмма, на участке после загрузки кода...

pvvx · 5 Апр 2018

ESP8266_NONOS_SDK_V2.0 из последнего на сегодня UDK, в нем же и собрано. Flash прописана как QSPI, 80MHz.
Красный, короткий, аналог действий SDK - загрузка и прямиком в deep_sleep с опцией без запуска WiFi.

Код:

#include "ets_sys.h"
#include "user_interface.h"

uint32 ICACHE_FLASH_ATTR user_rf_cal_sector_set(void)
{
    enum flash_size_map size_map = system_get_flash_size_map();
    uint32 rf_cal_sec = 0;

    switch (size_map) {
        case FLASH_SIZE_4M_MAP_256_256:
            rf_cal_sec = 128 - 5;
            break;

        case FLASH_SIZE_8M_MAP_512_512:
            rf_cal_sec = 256 - 5;
            break;

        case FLASH_SIZE_16M_MAP_512_512:
        case FLASH_SIZE_16M_MAP_1024_1024:
            rf_cal_sec = 512 - 5;
            break;

        case FLASH_SIZE_32M_MAP_512_512:
        case FLASH_SIZE_32M_MAP_1024_1024:
            rf_cal_sec = 1024 - 5;
            break;

        default:
            rf_cal_sec = 0;
            break;
    }

    return rf_cal_sec;
}

ICACHE_FLASH_ATTR void init_done_cb(void)
{
    system_deep_sleep_set_option(4);
    system_deep_sleep(1000000);
}

ICACHE_FLASH_ATTR void user_init(void)
{
    system_init_done_cb(init_done_cb);
}

Наглядно видим, что нам впаривает тут nikolz

Сдвиг на 33` мс от разницы на 1 символ выводимый ROM в UART о длине первой части загрузки boot. Даже это учтено в rapid-loader и ROM грузит всего 1 сегмент, а не три...

nikolz · 6 Апр 2018

pvvx написал(а):
Посмотреть вложение 6161
ESP8266_NONOS_SDK_V2.0 из последнего на сегодня UDK, в нем же и собрано. Flash прописана как QSPI, 80MHz.
Сдвиг на 33` мс от разницы на 1 символ выводимый ROM в UART о длине первой части загрузки boot. Даже это учтено в rapid-loader и ROM грузит всего 1 сегмент, а не три...

Ну и чем Ваш график отличается огт моего в самом начале темы?
Ничем.
Это Вы все что-то впариваете вместо того чтобы признать что 30 мс - это ваша выдумка,
а реально - это 80 мс.
И если внимательно посмотрите на свой и мой график то заметите, что SDK у меня грузится при 13 ма а у Вас при 35 ма.
-------------------------------------------
И в отличии от Вас я не трындю что Я все передлал и что у китайцев плохо.
Наоборот, я ничего собственно не кывырял и это сделать может любой.

nikolz · 6 Апр 2018

Выкладываю сообщение в сети, которое показывает один из вариантов развития WiFi
-----------------------------------
Marcus Mengs, создатель платформы P4wnP1 для совершения атак на USB, опубликовал прототип экспериментальной реализации стеганографического приложения для организации скрытого канала связи в WiFi. В предложенной разработке для обмена данными используются служебные Probe-кадры 802.11, которые в обычных условиях применяются для отправки широковещательных запросов для определения доступных по заданному каналу сетей.

Обмен данных с использованием Probe-запросов и ответов позволяет передавать информацию без привязки клиента к конкретной WiFi-сети. Более того, создаваемый скрытый канал связи не зависит от используемой частоты (WiFi-канала), когда клиент уже подключен к существующей беспроводной сети (т.е. будучи подключенным к WiFi можно создать ещё один скрытый канал связи).

OpenNews: Опубликован метод создания скрытых каналов связи в WiFi

pvvx · 6 Апр 2018

nikolz написал(а):
Ну и чем Ваш график отличается огт моего в самом начале темы?
Ничем.
Это Вы все что-то впариваете вместо того чтобы признать что 30 мс - это ваша выдумка,
а реально - это 80 мс.

Вы про что?
35 мс - это время от старта до конца загрузки rapid-loader-ом стандартного SDK.
График и коды для проверки представлены в его репе на git. Далее возможен опрос устройства, если грузился не китай-SDK, а типа meSDK и передача команды отключения питания управляющему устройству. За 2 мс думаю справится.
Простой вариант загрузчика с выходом в deep_sleep - это красненький график в прошлом соо и имеет не 80 мс, а 61 мс.
80 мс имеет вариант c передачей данных по WiFi от CNLohr -> https://esp8266.ru/forum/threads/ehnergopotreblenie-esp-itogi.3001/page-2#post-48643
Где применено комплексное решение из RapidLoader + meSDK.

И если внимательно посмотрите на свой и мой график то заметите, что SDK у меня грузится при 13 ма а у Вас при 35 ма.

Если внимательно посмотреть, то приведенный график в прошлом соо показан на стандартный SDK без применения каких-либо хаков, собранный исключительно по рекомендациям Espressif.
Это подписано в тексте. Код для проверки дан в сообщении.

pvvx · 6 Апр 2018

nikolz написал(а):
Выкладываю сообщение в сети, которое показывает один из вариантов развития WiFi
-----------------------------------
Marcus Mengs, создатель платформы P4wnP1 для совершения атак на USB, опубликовал прототип экспериментальной реализации стеганографического приложения для организации скрытого канала связи в WiFi. В предложенной разработке для обмена данными используются служебные Probe-кадры 802.11, которые в обычных условиях применяются для отправки широковещательных запросов для определения доступных по заданному каналу сетей.

Обмен данных с использованием Probe-запросов и ответов позволяет передавать информацию без привязки клиента к конкретной WiFi-сети. Более того, создаваемый скрытый канал связи не зависит от используемой частоты (WiFi-канала), когда клиент уже подключен к существующей беспроводной сети (т.е. будучи подключенным к WiFi можно создать ещё один скрытый канал связи).

OpenNews: Опубликован метод создания скрытых каналов связи в WiFi

Ну и что я вам трынжу уже годы? Типа этого:

pvvx написал(а):
все рекомендации уже давались несколько раз:
1) Отключите вывод всей отладки при старте (там опция есть)
2) Отключите ненужные калибровки RC генератора - он всё равно уйдет и не хило, т.к. плата не прогрета и т.д. и т.п. (вообще не нужен при отключении питания)
3) Загрузите запомненные значения инициализации WiFi
4) Используйте стандартные пакеты WiFi со штатными ответами.
5) Не ждите уморя погоды 20 мс после ответа AP.
7) Не используйте части кода которые не понимаете для входа в deep_sleep.
Итог будет ~65 мс (с учетом разогрева котла CPU (кварца) на угле - т.е. от события включения питания или RESET) и передатчик передаст всего 1 пакет, а не десяток.

Вам уже писал, что на пакет "probe request" ответ приходит стандартно и что данный пакет принимается всеми WiFi роутерами и прочим барахлом и в них есть встроенные команды логирования этих пакетов, что не требует перевода устройства в режимы снифферов и т.д. и не мешает работать по назначению.

Вы же пытаетесь тут доказать, что использование стандартного SDK от Espressif требующего 250 мс, плюс недобута в дополнительные 80 мс, плюс от 40 мс только включения WiFi в SDK - это лучший вариант, с итогом от 420 мс при передаче

Т.е. в более чем в 10 раз от возможных других реализаций.

pvvx · 6 Апр 2018

По пунктам объясняю ваши ошибки:

nikolz написал(а):
Т е у Вас нет никакого кода в ESP?
-----------------------------------------------------------
60 ms, похоже на правду.

61 мс - это минимальное время исполнения загрузки кода в сотню байт, плюс исполнения программы перевода ESP8266 в режим "deep-sleep" с таймером и Flash в режим "sleep". Работа с RTC сопровождается ожиданиями исполнения команд на её тактовой частоте RC генератора в ~6 мкс.
Загрузка кода обычно называется boot процедурой.
Исполняемый код обычно называют "программой".
Есть время старта системы до загрузки программы.
Есть время загрузки программы.
Есть время исполнения загруженной программы.

У меня 72..82 mc( там где ток становится меньше 30 ма) из них 60 мс - это исполнения кода из ROM и 12..20 мс nboot.

Это неверные данные. Они основаны на неправильных представлениях что и когда сколько потребляет у ESP8266.
Отдельных измерений вы не делали. Реперов не ставили.

Т е разница у Вас на время исполнения nboot в 12..20 ms .

Нет. Разница на много более.
Через ~30 мс происходит отключение лишнего потребления и включен доступ к исполнению кода любого размера из Flash на CLK CPU от 52-х или 102 МГц (по выбору, при кварце 26 МГц) и режиме работы Flash в QIO.

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

Нет - смотрите диаграмму в https://esp8266.ru/forum/threads/esp8266-sverxmaloe-potreblenie.3299/#post-50317

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

Нет, т.к. сильно зависит от размера загружаемого кода.
Минимальный и оптимальный размер имеет rapid-loader. После загрузки его 92-байт доступно:
1) Отключено лишнее потребление блоком WiFi, вывод частоты кварца на GPIO
2) Исполнение кода из Flash
3) Flash работает в режиме QIO и 2 x частоты кварца.
4) Загрузка стандартных сегментов SDK или вашей программы за 1..4 мс (6..10 килобайт в мс)
5) Старт SDK или вашей программы с обнуленным указателем стека (т.е. с нулевым использованием)
На это, с сигнала старта (RESET, или CH_PD, или подачи питания) уходит примерно 30 мс при кварце в 26 МГц.

у вас получилось не менее 60 мс, но не 30 мс, как Вы утверждали ранее.

30..35 мс - это старт системы в ROM, плюс загрузка и исполнение 1 байта в режиме загрузчика "Flash" после RESET, или CH_PD, или подачи питания.
Изменить ток потребления в этот период вы можете только сменив кварц на модуле.
Сократить это время - аналогично - поставьте штатный кварц на 40 МГц для программы в ROM у ESP8266, а не 26 МГц. Время изменится, но не в 40/26 раза.

ну согласитесь что 60, а не 30.

Не собираюсь соглашаться с вашей ложью.

про терминологию.
Если есть хотя бы одна команда , то это я и называю boot.

Вы будете в одиночестве. boot - это не то, что вы считаете.
ну и т.д.

Ваш измеритель похоже врет в десятки раз сокращая время или вы считать не умеете.

В диаграмме с примером от SDK показано, что ROM на загрузку 3-х сегментов общим размером 28368 байт минимального загрузчика SDK 2.0 тратит от 70 мс. ~500 байт в мс + ~0.14 мс на вывод символа в UART о размерах и контрольных суммах загружаемых блоков...
Rapid-Loader на это затрачивает до 4-х мс, исполняя данный код во Flash. Эта часть не грузится ROM, а исполняется непосредственно из Flash.

nikolz · 6 Апр 2018

Чтобы Вы постоянно не испаражнялись предлагаю Вам выложите свою прошивку dfituj лоадера с deep-sleep
и сравним результат измерения

pvvx · 6 Апр 2018

nikolz написал(а):
Чтобы Вы постоянно не испаражнялись предлагаю Вам выложите свою прошивку dfituj лоадера с deep-sleep
и сравним результат измерения

Это уже было несколько раз. И исходник давался.
Вам давались варианты и с анализом напряжения питания на входе ADC при старте и если менее - deep_sleep.
Из одной из версий его вы и взяли код для своего недо-бута.
В последний раз это было тут https://esp8266.ru/forum/threads/umenshaem-ehnergopotreblenie-esp8266.3010/page-2#post-49982
И график потребления этого дерьма и сравнение с аналогичными действиями в SDK 2.0 представлен тут https://esp8266.ru/forum/threads/esp8266-sverxmaloe-potreblenie.3299/#post-50317
Если добавить ваш rboot - будет за 300 мс.

nikolz · 6 Апр 2018

Вот мой nboot. можете сами сравнить со своим.
грузится и идет спать на 10 секунд.

pvvx · 6 Апр 2018

nikolz написал(а):
Вот мой nboot. можете сами сравнить со своим.
грузится и идет спать на 10 секунд.

Не вижу исходников. Сравнивать не с чем.
И что там вашего?

nikolz · 6 Апр 2018

pvvx написал(а):
Не вижу исходников. Сравнивать не с чем.
И что там вашего?

Рисуйте токи потребления и сравнивайте с работой вашего загрузчика по времени и по току.
Вы же постоянно наезжаете со своими разработками. которые якобы выполняются за 30 мс, и утверждаете что у меня неправильно измерение.
Вот вам прошивка ESP стартует и уходи спать старт можете смотреть на uart
-------------------
Вот еще прошивка (ndoot с 0000 romx с 2000)
Она отличается тем, что boot не уходит спать а грузит SDK и в user_init уходит в deep-sleep.
-------------------------------
По моим измерениям время исполнения первой проги 89 мс
--------------------------
Во втором варианте на загрузку SDK уходит еще 20 мс и нп включение WIFI еще 10 мс итого 120 мс
-----------------------------------------
Поэтому предлагаю вам прекратить ля-ля
и выложить прошивки или графики Ваших вариантов
1) rapid-loader+deep-sleep
2) rapid-loader+WiFi+deep-sleep.
Тогда будет видно без слов и ваших телепатических сеансов на сколько лучше ваше решение против стандартного с модифицированным rboot.
вот мои измерения:

nikolz · 6 Апр 2018

В качестве примера сжатие графика на интервале 280 секунд при кванте 0.5 мс без потери экстремумов
т е на обычном (Вашем) графике должно быть 570 тысяч отсчетов.

ESP8266. Сверхмалое потребление

Well-known member

Well-known member

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

Well-known member

Well-known member

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

Well-known member

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

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

Well-known member

Well-known member

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

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

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

Well-known member

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

Well-known member

Вложения

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

Well-known member

Вложения

Well-known member