Вопрос Deep sleep с пробуждением по кнопке

[pvvx]

Провел эксперимент, который объясняет почему получается 14 ма а не 4.
У меня получилось, что даже если не ставить таймер вообще то ESP каждые 20 секунд делает связь с роутером, т е включает активный режим процессора и передатчика в результате к 4 добавляется 10.

Смените роутер и настройки на нем beacon, подключите к нему разных клиентов - всё измениться... Уже сказано - зависит от погоды в эфире. Нету аппаратной фильтрации пакетов (или китайцы не написали) для WiFi драйвера. В 90% он тупит и жрет батарейку на китай-програмерские глупости.

 

[nikolz]

Смените роутер и настройки на нем beacon, подключите к нему разных клиентов - всё измениться... Уже сказано - зависит от погоды в эфире. Нету аппаратной фильтрации пакетов (или китайцы не написали) для WiFi драйвера. В 90% он тупит и жрет батарейку на китай-програмерские глупости.

Вы тоже пример с китайцев взяли.
Постоянно надо фильтровать ваши ответы от ругательств в чей-нибудь адрес.
Покажите пример китайцам - поставьте фильтр пакетов в ответы.

 

[pvvx]

Вы тоже пример с китайцев взяли.
Постоянно надо фильтровать ваши ответы от ругательств в чей-нибудь адрес.
Покажите пример китайцам - поставьте фильтр пакетов в ответы.

Обойдетесь. Вам и готовое дай и ещё не ругаться
Сначала вам надо исправиться - отвечать "слушаюсь и повинуюсь". А то кроме спама, рекламы никчемного барахла и запутывания вопрошающих от вас ничего нема. Потом уже буду думать "казнить или помиловать".
Вы уже десятое соо пишите про потребление в WiFi LIGHT, а так и не разобрали что и почему, а ранее постоянно рекламировали, что должно быть менее 1.5 мА (по докам от врунов из Espressif).

 

[nikolz]

Обойдетесь. Вам и готовое дай и ещё не ругаться
Сначала вам надо исправиться - отвечать "слушаюсь и повинуюсь". А то кроме спама, рекламы никчемного барахла и запутывания вопрошающих от вас ничего нема. Потом уже буду думать "казнить или помиловать".
Вы уже десятое соо пишите про потребление в WiFi LIGHT, а так и не разобрали что и почему, а ранее постоянно рекламировали, что должно быть менее 1.5 мА (по докам от врунов из Espressif).

Менее 1.5 это Вы путаете, я написал что у меня 4.5 ма получилось, а получить как в документации пока не получается.

 

[Makc1806]

С light_sleep печалько...
Извиняюсь заранее, т.к. не по теме, но может кто знает, есть ли возможность управлять множителем процессора, как это делается для atmega, например:

Спойлер: про уменьшение частоты с примером и обсуждением

Ну, если в даташитах не умеете, так смотрите классическую статью Гэммона, там про экономию энергии всё написано. В частности про уменьшение частоты с примером и обсуждением (начиная со слов "Altering the processor frequency")

Слава Богу, это в одну строчку делается, если power.h включить

1 #include <avr/power.h>
2
3 void setup(void) {
4 clock_prescale_set (clock_div_256); // уменьшаем частоту в 256 раз
5 ...
6 }

Вопрос о ЦП esp8266 естественно, а не avr.

 

[pvvx]

С light_sleep печалько...
Извиняюсь заранее, т.к. не по теме, но может кто знает, есть ли возможность управлять множителем процессора, как это делается для atmega, например:

Спойлер: про уменьшение частоты с примером и обсуждением

Ну, если в даташитах не умеете, так смотрите классическую статью Гэммона, там про экономию энергии всё написано. В частности про уменьшение частоты с примером и обсуждением (начиная со слов "Altering the processor frequency")

Слава Богу, это в одну строчку делается, если power.h включить

1 #include <avr/power.h>
2
3 void setup(void) {
4 clock_prescale_set (clock_div_256); // уменьшаем частоту в 256 раз
5 ...
6 }

Вопрос о ЦП esp8266 естественно, а не avr.

Нет смысла переключать частоту. Разница по потреблению будет в пару процентов. WiFi блоку частоту не поменять, а он основной потребитель.
В ESP8266 есть PLL и доступ к нему через команды ROM-BIOS rom_i2c_readReg(103,4,1) и rom_i2c_writeReg(103,4,1,x).
А нет смысла, т.к. проц в основном стоит на команде ожидания прерывания, а система работает по событиям. Обработал событие и опять сидит на команде ожидания, которая уменьшает уровень потребления. В итоге переключение 80/160 МГц не имеет больших различий... Выходит, что больше производительность - больше потребление и оно практически линейно. Уменьшите частоту - система будет тупить, а т.к. на обслуживание WiFi и системы уходит почти всегда одинаковое кол-во тактов в сек активности CPU, то разница потребления будет минимальна. Динамическое переключение кроме 1 к 2 через PLL переключает всю периферию CPU, плюс PLL долго стабилизируется и на ходу это делать затратно. Потроха, кроме CPU, всё равно работают и жрут.
Пример с RTL00 модулем с RTL8710AF, если CPU в основном исполняет команду IDLE и обслуживает только RTOS (практически нет задач), включена вся стандратно необходимая переферия (таймеры, UART-ы, ...):
166.6MHZ - 21 mA
83.3MHZ - 15 mA
41.6MHZ - 11 mA
20.8MHZ - 9.5 mA
4MHZ - 8 mA
Если это Arduino и сделано работа как в ESP, то потребление:
166.6MHZ - 63 mA
83.3MHZ - 55 mA
(далее не измерял, т.к. это глупо, гонять в таком режиме CPU)
Если включен режим засыпания CPU и просыпания на обработку событий, то всегда менее 6.4 мА, в независимости от его частоты и всё активно.
(Приведенные замеры не точны для всех случаев - зависит от процессов, работающего светодиода на модуле и стабилизатора 3.3В, произведены в стандартной "AT" прошивке от производителя).
А в режиме с отключением периферии между beacon (аналога WiFi LIGHT EPS) - около 2 мА если увеличить время между baecon (график со стандартной частотой следования beacon приведет ранее и в этой теме).

Лучше правильнее пишите код и не используйте Arduino (и ESP8266 ).

 

[nikolz]

Некоторая информация о Light-sleep.
из документации:
Пользователи могут принудительно включить Light-sleep, вызывая API-интерфейсы принудительного ожидания и выключая RF
подробнее в on force sleep APIs, please refer to Section 3.7 Force Sleep APIs in ESP8266 Non-OS SDK API Reference and Section 4.12 Force Sleep APIs in ESP8266 RTOS SDK API Reference.
-------------------------------
Во время Light-sleep CPU приостанавливается и не реагирует на сигналы и прерывания
От периферийных аппаратных интерфейсов. Поэтому, ESP8266 необходимо разбудить через
Внешний GPIO. Процесс пробуждения составляет менее 3 мс.
--------------------
Режим спящего режима можно использовать в сценариях, где приложения должны оставаться
Подключенный к маршрутизатору и может реагировать на передачу данных с маршрутизатора в режиме реального времени.
Перед тем как принимать команды, CPU может простаивать. Примером может служить переключатель Wi-Fi,
Процессор не работает большую часть времени и только выполняет операции GPIO до получения управляющей команды.
----------------------
Если интервал задачи короче, чем интервал маяка DTIM, система не может перейти в режим «Спящий режим» как на рис.

Более экономично работать в Deep-Sleep
При этом тоже можно использовать просыпание от кнопки.
В режиме глубокого сна чип можно разбудить и инициализировать импульсом низкого уровня
Сгенерированный на выводе EXT_RSTB через внешний IO.

Если автоматическое пробуждение и внешнее пробуждение должны быть включены одновременно, пользователям необходимо добавить внешнюю логику.
--------------------------
Deep-sleep (Глубокий сон) может использоваться в приложениях с низким энергопотреблением или в сценариях, где передача данных не требуется в течение большей части времени. Устройство просыпается от глубокого сна
для измерения и загрузки данных, а затем снова переходит в режим глубокого сна. Устройство может
также сохранять данные в памяти RTC (которые все еще могут сохранять данные в режиме глубокого сна), а затем
Отправить их за один раз .
------------------
И самая главная рекомендация в документации:
Из-за малого времени (<3 мс) пробуждения из режима сна Light-sleep, если приложение спит
Менее 2 секунд, тогда режим Light-sleep предпочтительнее для экономии энергии;
Если приложение засыпает больше чем на 2 секунды, рекомендуется режим deep-sleep.
-------------------------------
Кто работает с nodemcu на луа, сообщаю, что по умолчанию на луа режим Light-sleep средний ток потребления 33 ма (проверил экспериментально ).

 

[pvvx]

И самая главная рекомендация в документации:
Из-за малого времени (<3 мс) пробуждения из режима сна Light-sleep, если приложение спит
Менее 2 секунд, тогда режим Light-sleep предпочтительнее для экономии энергии;
Если приложение засыпает больше чем на 2 секунды, рекомендуется режим deep-sleep.
-------------------------------
Кто работает с nodemcu на луа, сообщаю, что по умолчанию на луа режим Light-sleep средний ток потребления 33 ма (проверил экспериментально ).

Ну и нафиг оно сдалось? Работать в ESP8266 с Light-sleep WiFi невозможно. Не легче ли махнуть модуль, который правильно работает в Light-sleep и думать в ПО, что он включен в Light-sleep не требуется ? Различие цены в +40 руб он вычерпает у первой четверти первой батарейки. Если включен "режим экономии энергии" (так он назван в RTL-ах), то в приложении особо думать не требуется - меняется только время первого пинга (модуль то спит между beacon) и реакция на внешние сигналы, такие как UART - первый символ только пробуждает модуль, а далее гоните сколько хотите, что WiFi поток, что UART поток или всё что по работает по прерываниям и разницы что "режим экономии энергии" включен не увидите, кроме как по потреблению Тем более есть возможность задания какое устройству входит или нет в режим "экономии".

 

[nikolz]

Ну и нафиг оно сдалось? Работать в ESP8266 с Light-sleep WiFi невозможно. Не легче ли махнуть модуль, который правильно работает в Light-sleep и думать в ПО, что он включен в Light-sleep не требуется ? Различие цены в +40 руб он вычерпает у первой четверти первой батарейки.

Я привел информацию, которая доступна и отражает существо вопроса.
Выводы делает каждый самостоятельно.
-----------------------
Лучшее - враг хорошего.

 

[pvvx]

Я привел информацию, которая доступна и отражает существо вопроса.
Выводы делает каждый самостоятельно.
-----------------------
Лучшее - враг хорошего.

Реализация Light-sleep в ESP сделана ужасно - это нельзя отнести даже к "хорошего". Если его не вырубать на время работы с WiFi, то LwIP падает, нельзя назначать таймерные события и многое другое. Сколько раз говорить?
Но главное, что это проблема чисто криво-писако-китай-Espressif-софт. По тому и исходники спрятаны - там кошмар и им стыдно их показывать.
В ROM-BIOS ESP сделан другой режим Light-sleep - с просыпанием по i/o. Но они его скрывают, т.к. не вписался в их систему (код рассчитан на другой кварц, а в текущем неправильно восстанавливает PLL и WiFi не будет работать...). Его можно использовать только в своем SDK.

 

[nikolz]

Реализация Light-sleep в ESP сделана ужасно - это нельзя отнести даже к "хорошего". Если его не вырубать на время работы с WiFi, то LwIP падает, нельзя назначать таймерные события и многое другое. Сколько раз говорить?
Но главное, что это проблема чисто криво-писако-китай-Espressif-софт. По тому и исходники спрятаны - там кошмар и им стыдно их показывать.

У меня работает с колбеком по таймеру, передачей по UDP и включенным Light-sleep.
Тестировал долго, проблем не было. Меня устраивает.
но мне больше подходит deep-sleep.
Полагаю,Light-sleep можно ставить ,чтобы уйти от среднего тока 70 ма к 15 ма при малой загрузке процессора.
При этом ничего городить специально в программе не надо кроме одной команды.

 

[pvvx]

У меня работает с колбеком по таймеру, передачей по UDP и включенным Light-sleep.
Тестировал долго, проблем не было. Меня устраивает.
но мне больше подходит deep-sleep.
Полагаю,Light-sleep можно ставить ,чтобы уйти от среднего тока 70 ма к 15 ма при малой загрузке процессора.
При этом ничего городить специально в программе не надо кроме одной команды.

Ну а почему его нельзя использовать всегда, когда автономное питание?
Причину же выявили - горе программеры Espressif. Другой причины там нет. Сам чип в этом не виноват и имеет всё необходимое для этого.
Так-же почему не реализовано просыпание по кнопке?
Что нужно для автономных датчиков IoT?
Главные функции, по приоритету:
Просыпание по внешнему событию:
1) по смене состояния на пине
2) по уровню на ADC
3) просыпание по таймеру
4) просыпание по получению данных по имеющимся интерфейсам (UART, SPI, ...)

Т.е. ESP8266 не вписывается в данную тему и тему IoT!

 

[nikolz]

Ну а почему его нельзя использовать всегда, когда автономное питание?
Причину же выявили - горе программеры Espressif. Другой причины там нет. Сам чип в этом не виноват и имеет всё необходимое для этого.
Так-же почему не реализовано просыпание по кнопке?

просыпание по кнопке есть и оно ранее уже описано.
Но как сказано в документации оно выгодно при малом времени сна.
из своих экспериментов я обнаружил, что ESP в этом режиме становится активным каждые 20 секунд. в результате вместо 2-4 ма среднего тока имеем 14 ма.
Если используем deep-sleep то при сне в 5 секунд имеем средний ток 10 ма.
т е получается, что спать болле чем 5 секунд лучше в режиме deep-sleep.
Кроме того, в режиме deep-sleep у меня ESp соединяется и передает данные за время 370-540 mc.
В режимеLight-sleep мне не удалось получить меньшего времени.
Но возможно, что кому-то лучше иначе.

 

[pvvx]

просыпание по кнопке есть и оно ранее уже описано.
Но как сказано в документации оно выгодно при малом времени сна.
из своих экспериментов я обнаружил, что ESP в этом режиме становится активным каждые 20 секунд. в результате вместо 2-4 ма среднего тока имеем 14 ма.
Если используем deep-sleep то при сне в 5 секунд имеем средний ток 10 ма.
т е получается, что спать болле чем 5 секунд лучше в режиме deep-sleep.
Кроме того, в режиме deep-sleep у меня ESp соединяется и передает данные за время 370-540 mc.
В режимеLight-sleep мне не удалось получить меньшего времени.
Но возможно, что кому-то лучше иначе.

Просыпание из полного отключения - никакого потребления до события. Всё остальное - это ваша реклама ESP и ваше "Меня устраивает".
А многих это не устраивает, т.к. это базовая функциональность для IoT датчиков.
Заключение тут возможно только одно - без дополнительной системы модуль ESP8266 не годиться для применения в вариантах "IoT датчиков". Даже его цену и надо рассматривать с учетом этого и выходит, что реализация "IoT датчика" на нем выходит дороже, чем на других модулях WiFi.
У вас есть возможность решить это только такими путями:
1) Ругаться матом во всех темах форумов Espressif, чтобы исправили код.
2) Предложить решение с минимальной ценой, кодами и прошивками для всех.

 

[nikolz]

Просыпание из полного отключения - никакого потребления до события. Всё остальное - это ваша реклама ESP и ваше "Меня устраивает".
А многих это не устраивает, т.к. это базовая функциональность для IoT датчиков.

Это из проблема.

 

[pvvx]

Это из проблема.

Это вопрос темы, если не заметили.

Как-бы уже обсудили - если использовать всякие sleep, то с ESP8266 мы не вписываемся даже в нормы BLE. Выходит, что только deep-sleep. Но для управления выхода из него по кнопке надо ставить внешнее оборудование. А раз уж ставится внешнее - то желательно решить варианты указанные по списку ранее. Цена от это этого почти не зависит - только по кнопке или пробуждение ещё по другим событиям.
"Cкупой платит дважды, тупой трижды, а ... " ....

 

[nikolz]

Это вопрос темы, если не заметили.

Как-бы уже обсудили - если использовать всякие sleep, то с ESP8266 мы не вписываемся даже в нормы BLE. Выходит, что только deep-sleep. Но для управления выхода из него по кнопке надо ставить внешнее оборудование. А раз уж ставится внешнее - то желательно решить варианты указанные по списку ранее. Цена от это этого почти не зависит - только по кнопке или пробуждение ещё по другим событиям.
"Cкупой платит дважды, тупой трижды, а ... " ....

Вы опять передергиваете
Я понимаю, что Вы рекламируете свои свалки
Попробую объяснить, для тех кто читает(Вам бесполезно )
Ставить ничего не надо если не требуется совместить в режиме deep-sleep внешнюю кнопку и автоматическое пробуждение по таймеру.
Что же касается режима Light-sleep от кнопки или от таймера то это тоже описано в документации (выше я это привел и дал пример для ардуино)
Я этот режим от кнопки подробно не изучал так как мне это не требуется (выше тоже про это писал)
Поэтому я не кричу на весь форум что решаю проблемы всего мира ( Это Ваша стезя)
Я лишь делюсь информацией и собственными результатами без заявок на истину в первой инстанции
Кому-то это может быть полезно, ну а иначе - не обращайте внимание.

 

[pvvx]

Вы опять передергиваете
Я понимаю, что Вы рекламируете свои свалки
Попробую объяснить, для тех кто читает(Вам бесполезно )
Ставить ничего не надо если не требуется совместить в режиме deep-sleep внешнюю кнопку и автоматическое пробуждение по таймеру.
Что же касается режима Light-sleep от кнопки или от таймера то это тоже описано в документации (выше я это привел и дал пример для ардуино)
Я этот режим от кнопки подробно не изучал так как мне это не требуется (выше тоже про это писал)
Поэтому я не кричу на весь форум что решаю проблемы всего мира ( Это Ваша стезя)
Я лишь делюсь информацией и собственными результатами без заявок на истину в первой инстанции
Кому-то это может быть полезно, ну а иначе - не обращайте внимание.

Я уже привел решение вопроса по теме. И второе, более простое и дешевое решение - использование RTL871x модулей. И третье - Вопрос - Deep sleep с пробуждением по кнопке
Вы-же предлагаете что-то другое, где не выполняется:
"Deep sleep с пробуждением по кнопке".
Т.е. городите "спам"?

Из имеющихся дешевых источников питания в быту и желаемого времени работы среднего датчика IoT, если обобщить, то требуется средний уровень потребления менее 5 мА, желательно 2 мА. Только такие альтернативы могут конкурировать с deep_sleep, а все ваши предложения - не катят.

 

[nikolz]

Рассказываю как сделать пробуждение по кнопке и по времени в одном флаконе.
Для этого используем режим deep-sleep, который настраивается на требуемый тайм.
Кнопку подключаем к пину RST через параллельно соединенные резистор ( килоом от 5 ) и конденсатор( мкф от 10)
(Вот и вся дополнительная логика).

 

[pvvx]

Рассказываю как сделать пробуждение по кнопке и по времени в одном флаконе.
Для этого используем режим deep-sleep, который настраивается на требуемый тайм.
Кнопку подключаем к пину RST через параллельно соединенные резистор ( килоом от 5 ) и конденсатор( мкф от 10)
(Вот и вся дополнительная логика).

Время реакции должно быть до 0.2 секунд. Более не согласуется с ожидаемой реакцией у людей, а кнопка сделана для людей, а не для робота. По нажатию кнопки, должно произойти действие - управляемое устройство должно среагировать. Иначе надо изменить людей, чтобы они смогли таким пользоваться, но это уже не относится к решению на ESP8266.
По задаче ещё опрос кнопки на несколько нажатий и времени удержания. Как пример передача сигнала SOS - попробуйте настучать и определите временные рамки реакции системы.

Тогда ваша схема начинает обрастать – ещё выход какого-то порта должен задавать разрешение разряда кондера и вход другого порта – чтением состояния кнопки. Тоже можно через резисторы, но кто будет опрашивать длительность первого нажатия, пока система SDK не загрузилась? Будете ставить мою модифицированную версию SDK? У неё реакция, время загрузки до входа в пользовательский код, быстрее и укладывается в 0.2 сек. Туда, далее, входит и время инициализации кода WiFi до включения обработки таймеров и зависит исключительно от закрытой части китай-куска-SDK и не регулируется. Можно это обойти – распределение на несколько процессов описано в моей сборке, но не задействовано… А я не полезу больше в ESP8266, тем более в Arduino к нему. Инить наверно надо в AP+ST, а именем AP задавать код. Внешнее устройство выловит включение AP по MAC, считывая имя AP получит код… Далее связь может идти от staion ESP8266.

Вы это, или примерно такое, опишите?

Т.е. готовых решений нет и пользователю проще поставить внешний MCU, программированный хоть на Arduino.