Минимальное время активного режима ESP

[nikolz]

Информация к размышлению.
провел такой эксперимент.
В лоадер , который грузится с адреса 0 во флеш и при старте ESP загружает SDK и выполняет запуск ,поместил вызов режим deep-sleep.
Т е предполагается что в реале ESP просыпается читает датчики. Если передавать ничего не надо то записывает показания в память RTC и ложится спать.
Цель эксперимента - определить минимальное время активности и потребляемый ток.
В результате получилось следующее:


На участке с надписью " исполнение программы загрузчика" исполняется код лоудера и собственно чтение данных с датчиков.
До этого происходит старт и исполнения скрытой части кода.
-----------------------
Резюме: Минимальное время активности ESP составляет от 80 ms.
----------------------
Далее для сравнения представлена картинка для обычной работы deep-sleep с передачей сообщения на сервер

===========================================
Теперь оценим энергозатраты на работу ESP в двух режимах.
===================================
Первый режим соответствует первой картинке.
В этом режиме ESP8266 читает информацию с датчика и либо пишет или нет ее в RTC и ложится снова спать без связи с сервером.
Интегрируем функцию потребляемого тока с отключенным WIFI получаем значение
2.3 ma*s. Для напряжения питания 3 вольта требуемая энергия составит примерно 0.007 Дж.
---------------------------------------
Второй режим соответствует второй картинке.
В этом режиме ESP8266 отсылает данные на сервер перед тем как лечь спать.
15.3 ma*s. Для напряжения питания 3 вольта требуемая энергия составит примерно 0.05 Дж.
===============================
Резюме: Первый режим примерно в 7 раз более экономичный по энергозатратам.
=========================================
Теперь давайте оценим длительность работы ESP от двух батареек по 1.5 в.
Батарейка формата AA может отдать примерно от 3 до 10 кДж.
Батарейка формата AAА может отдать примерно от 1.5 до 4 кДж.
-------------------------
Примем значение энергии батареек 3 кДж.
Предположим что eSP спит 1 минуту. Просыпается читает датчик и отсылает данные на сервер. Для этого режима будет затрачено 0.05 Дж.
При этом батареек хватит на 3000/0.05=60 000 минут, т е на 1000 часов или 50 дней.
--------------------------------
Другие варианты Вы можете рассчитать самостоятельно на основе приведенной выше информации.

 

[pvvx]

Не ходите кругами.
При старте, в процедуре ROM-BIOS ESP8266, на скорости 74880 Baud посимвольно выводит сообщение о загрузке кода SDK или Arduino.
Минимальное значение ко-ва выводимых символов около 230 шт.

ets Jan  8 2013,rst cause:x, boot mode:(x,x)

load 0x40100000, len 1396, room 16
tail 4
chksum 0x89
load 0x3ffe8000, len 776, room 4
tail 4
chksum 0xe8
load 0x3ffe8308, len 540, room 4
tail 8
chksum 0xc0
csum 0xc0

Вывод в UART производиться с ожиданием передачи каждого символа.
В итого, при 10 битах на символ и скорости бит в 74880 имеем 230*10/74880 = 0.030716 сек только на вывод символов в UART о загрузке.
К этому складывается время загрузки на низкой частоте по SPI с Falsh (сотня байт на 5 мс при коротких блоках).
Сокращение времени работы от батарейки на анализ датчика или ADC на ESP8266 возможно получить только написав всё свое, включая SDK.
Пример более трехкратного сокращения времени загрузки кода давался в RapidLoader-е несколько лет назад:

Время старта (включения) deep_sleep в китайском SDK составляет от 100 мс, после подачи команды выхода в deep_sleep.
Минимальное время обработки начальной инициализации SDK (очистки RAM, ожидания установки PLL на кварц в 26 МГц, включение таймеров и вывод сообщений в UART уже из кода SDK) - не менее 100 мс.
Итог печальный, т.к. до инициализации WiFi ещё не дошли, а уже имеем потребление к 70 мА в течении более 200 ms.
Если дадим запрос значения ADC, то получим ещё задержку на реализацию исполнения замера ADC в SDK. Она там не хилая и в цикле разбавлена ожиданиями в десятки мс.

Но, если совместить части моих исходников и решений, то получим, что нормально измерить с помощью INA219 импульс потребления не удастся Придется искать что-то покруче...
Для ознакомительного теста, можно взять лоадер (приложен к сообщению - бинарик в 1072 байта) c такими функциями:
Модуль включается, опрашивает встроенный ADC и если значение менее половины шкалы, то засыпает на примерно 10 сек. Затем опять просыпается и всё повторяется.
Каждое просыпание в UART выводится 16-ти битное значение ADC 0...65000 (полученное суммой нескольких фактических замеров SAR для уточнения и усреднения).
Если значение более половины шкалы ADC, то производиться ускоренная загрузка (принцип RapidLoader и его же кусок кода) уже полного SDK.
Т.е. лоадер выполняет функцию ожидания зарядки АКБ, к примеру от солнечной панели, и когда зарядиться, то будет дан старт SDK/Arduino с уже включением WiFi и ...

@nicolz - Замерьте на INA219 сами, т.к. с такой низкой дискретностью выкладывать графики для данного тестового лоадера противно ... Выглядит мерзко, в динамике, при работе через websocket на RTL и dygraph.js:

Лоадер пишется в нулевой адрес Flash. Дальнейшие проблемы загрузчиков и dev-плат по поводу прошивки разными программами программаторов на ESP не принимаются - если прошьете, то и поймете по чему

Это предел "лояльного подхода" давно сделанного на коленке на ESP, а полное отключение вывода ROM-BIOS в UART на ESP возможно только с применением дополнительного управляющего MCU с завязкой управления и ног Flash... В итого выходило от 30 мс, простив 0.2...3 мс у других SoC с аналогичной задачей (замер встроенным ADC, выбор действия/продолжения сна). В остатке только: ESP не годиться для экономичных решений и следящих датчиков... Ваш теоретический подход так-же не годиться - когда перейдете к примерам и тестам вылезет многое другое, такие вещи как длительный старт инициализации самого CPU (к примеру время на отсчеты тактов стабилизации кварцевого генератора и ожидания синхронизаций в PLL - только это уже составляет большую часть при манипулировании ошибками в ROM-BIOS для ускорения старта пользовательского кода...).

 

[pvvx]

Аналог на Arduino (т.е. замер встроенным ADC, выбор действия/продолжения сна и старт с отключенным WiFi):

Ток зеленый, выбран самый короткий по длительности из пачки - т.е. чуть более 230 мс cо стартом из depp_sleep в режиме отключенного WiFi:

Спойлер: Использованный код Скетча

Тестированный (накаляканный для теста) пример скетча. Ветка включения WiFi в тесте не отрабатывает - т.к. интересует минимум, но отключает WiFi, если до того был включен...

#include <Arduino.h>
#include <ESP8266WiFi.h>

const char* ssid     = "your-ssid";
const char* password = "your-password";

char flag_test_dc = 0;

void setup() {
  Serial.begin(74880);
}

void loop() {
  if (!flag_test_dc) {
    int A = analogRead(A0);
    Serial.printf("ADC:"); Serial.println(A);
    if (A > 1024 / 2) {
      WiFi.mode(WIFI_STA);
      WiFi.begin(ssid, password);
      while (WiFi.status() != WL_CONNECTED) {
        delay(100);
        Serial.print(".");
      }
      Serial.println("Only 'WiFi Off'!");
      Serial.println("Wifi Off...");
      WiFi.mode(WIFI_OFF);
    }
    flag_test_dc = 1;
  }
  else {
    ESP.deepSleep(10000000, WAKE_RF_DISABLED);
  }
}

Наглядно видно, что время включения deep_sleep от 100 мс, в любом режиме (в SDK стоит тайм-аут на софт. таймере на 100 мс до выполнения завершения процесса deep_sleep, а до того производиться калибровка RC генератора псевдо RTC на десяток мс - итог выполнение включения deep_sleep всегда более 100 мс). По этому ваш, nikolz, график с подписью "В результате получилось следующее:" в первом сообщении совершенно не понятен. Как поклонникам Ардуино и Espressif SDK сократить время выхода в deep_sleep?
Единственное сокращение времени старта, применимое в Espressif SDK, можно сделать, встроив свою процедуру опроса датчика/ADC в вызов user_rf_pre_init() или user_rf_cal_sector_set() вызываемую в самом начале старта инициализации SDK. Но стандартные функции из SDK там работать не будут - "диспетчер" задач (ets_run()) там ещё не запущен. Т.е. SDK от Espressif не предусматривает построение на её базе автономных устройств и вам придется бороться с ним по полной или взять другой WiFi SoC.

 

[pvvx]

Для напряжения питания 3 вольта требуемая энергия составит примерно 0.007 Дж.

1 Джоуль это 1 Вт за сек
Среднее потребление на вашем графике до функции старта инициализации SDK (исполнение команды ожидания прерывания при калибровках, указывающее на провал до минимума в 5 мА) это более 33 мА за 0.12 сек при 3.3В. Итого 3.3*0.033*0.12 -> 0.013 Дж. Для выхода в deep_sleep в SDK надо прибавить ещё 0.1 сек с потреблением к 40 мА (те-же 0.013 Дж).
Солевая AAA – это порядка 1.5 кДж, алкалиновые и т.д. около 4 кДж (но разные сроки эксплуатации). Для 3В надо два элемента. В минимуме получим итого: 3000 Дж / 0.026 Дж – к 115 тысячам стартовых опросов без запуска WiFi. Если опрос раз в 10 сек –> предел 13 суток работы без включения WiFi. 13*24*60*60/10 = 112320 стартов. C WiFi и дешевыми AAA всё плохо. Они не в состоянии отдавать более 100 мА, что требуется для работы WiFi у ESP8266 – при разряде и таком токе имеют уже значительный провал по напряжению, что выльется в установку доп. стабилизаторов или DC-DC, ещё ухудшив ситуацию в два раза…
И если уж идете на такое, то проще и дешевле поставить внешний MCU.

Отключение вывода сообщений у ESP8266 выуживается за счет ошибки в ROM-BIOS загрузчике и подстановке в разметке первого сектора flash нулевых значений кол-ва сегментов для загрузки... (У RTL серии "A" это устанавливается записью флага в eFuse).

 

[nikolz]

Аналог на Arduino (т.е. замер встроенным ADC, выбор действия/продолжения сна и старт с отключенным WiFi):
Наглядно видно, что время включения deep_sleep от 100 мс, в любом режиме (в SDK стоит тайм-аут на софт. таймере на 100 мс до выполнения завершения процесса deep_sleep, а до того производиться калибровка RC генератора псевдо RTC на десяток мс - итог выполнение включения deep_sleep всегда более 100 мс). По этому ваш, nikolz, график с подписью "В результате получилось следующее:" в первом сообщении совершенно не понятен. Как поклонникам Ардуино и Espressif SDK сократить время выхода в deep_sleep?
Единственное сокращение времени старта, применимое в Espressif SDK, можно сделать, встроив свою процедуру опроса датчика/ADC в вызов user_rf_pre_init() или user_rf_cal_sector_set() вызываемую в самом начале старта инициализации SDK. Но стандартные функции из SDK там работать не будут - "диспетчер" задач (ets_run()) там ещё не запущен. Т.е. SDK от Espressif не предусматривает построение на её базе автономных устройств и вам придется бороться с ним по полной или взять другой WiFi SoC.

Добрый день,
хочу привести результаты, которые показывают, что время загрузки может быть меньше 100 мс на Вашем SDKnoWiFi но при этом начальный вывод текста никуда не делся а присутствует.
вот картинка работы eSP на SDK 2.1.0..
Алгоритм такой: Esp просыпается отсылает по UDP привет серверу получает ответ и ложиться спать на 5 секунд.


Как видно из графика, время загрузки составляет 100 мс.
При этом все время активности составляет 320 mc.
-------------------------------------
А вот график работы Вашего SDKnoWIFI.
Алгоритм такой: ESP просыпается и снова в лоудере ложится спать на 1 сек.

Как видим время активности составляет 83 ms.
Т е всего на 17 ms.
------------------------
Могу предположить, что Ваша гипотеза о существенном сокращении времени загрузки при удалении начальной записи ошибочна.

 

[pvvx]

1) От куда 227 КБ загрузки?
2) Пример запуска с проверкой значения ADC дан и вы все сами можете измерить

 

[nikolz]

1) От куда 227 КБ загрузки?
2) Пример запуска с проверкой значения ADC дан и вы все сами можете измерить

Согласен, ошибся.Исправил.
--------------------
Вот еще одно доказательство, что меньше 100 даже с выводом сообщения.
Взял rboot и вставил deep-sleep получилось следующее:

 

[nikolz]

Если просто посчитать исходя из скорости вывода и числа байт сообщения, то получится 1000*((74880/9/100)^-1)=12 ms.
Т е можно получить минимальное время активного режима 74 ms без сообщения и 86 с сообщением.
--------------
Подскажите, как убрать сообщение?
Спасибо