ESP32C3 заглушка DeepSleep перестала исполняться

[pvvx]

Беспроводная связь делается так, как и на версии MAX:

На время отладки вставляется переходник USB-C->USB-A, а в него любой USB WiFi/BLE/Zigbee.
Когда всё отладите - разбираете корпуса и припаиваете короткими проводами и размер становится совсем крошечным...

 

[pvvx]

И явно не для автономной работы.
Цена тоже раза в 4 выше.

Потребление не больше ESP32, а меньше. Особенно пиковое.
Цена полностью окупается производительностью и NPU.

 

[pvvx]

Вы сами написали:
Требует всего в среднем 93 мА по 5В с работающим USB-BT адаптером...

У ESP32-C3 аналогичное потребление при включенном RF на прием в BLE, а при TX лучше даже не думать... Всё есть в документации к ESP32-C3.
И в LuckFox никто вам не мешает опускать CLK CPU до минимума, когда работы нет. Стандартно там несильно понижают-повышают CLK...
И замеры даны при SD карте + активном EThernet + USB-BT на приеме.

 

[pvvx]

Любой современный смартфон потребляет в среднем менее ESP32-C3. И это при активности WiFi, BT, GSM.

 

[nikolz]

У ESP32-C3 аналогичное потребление при включенном RF на прием в BLE, а при TX лучше даже не думать... Всё есть в документации к ESP32-C3.
И в LuckFox никто вам не мешает опускать CLK CPU до минимума, когда работы нет. Стандартно там несильно понижают-повышают CLK...
И замеры даны при SD карте + активном EThernet + USB-BT на приеме.

Заказал его. Буду изучать.

 

[pvvx]

Это полное безобразие – пытаюсь в документации Espressif по ESP32-H2 найти потребляемый чипом ток в рабочем режиме. Но его нет.
Стесняются написать, а приводят значения только для режима “Modem-sleep”. Если сравнивать по ним, тогда у древних WiFi RTL872x выходит от 10 раз меньше на любой частоте CPU – до 1.6 мA...
Для кого такая документация и почему не написать реальные показатели?

 

[pvvx]

Начитавшись такой документации все ИИ c включенным поиском по сети бредят аналогично о каком-то sleep, когда вопрос заходит о Zigbee роутере, который должен находиться в вечном приеме, кроме моментов передачи принятой информации. Это схоже с поведением WiFi AP.
Т.е. узнать сколько потребляет ESP32-H2 в режиме Zigbee router или аналогичных нет никакой возможности не купив этот чип, PowerProfiller и прочие устройства для измерений.
Минимально нормальный PowerProfiler стоит от $1000.
По картинкам приложенным к ESP-IDF наблюдается полное неумение пользоваться таким PowerProfiler...

 

[nikolz]

Начитавшись такой документации все ИИ c включенным поиском по сети бредят аналогично о каком-то sleep, когда вопрос заходит о Zigbee роутере, который должен находиться в вечном приеме, кроме моментов передачи принятой информации. Это схоже с поведением WiFi AP.
Т.е. узнать сколько потребляет ESP32-H2 в режиме Zigbee router или аналогичных нет никакой возможности не купив этот чип, PowerProfiller и прочие устройства для измерений.
Минимально нормальный PowerProfiler стоит от $1000.
По картинкам приложенным к ESP-IDF наблюдается полное неумение пользоваться таким PowerProfiler...

ESP32-H2 Thread/Zigbee Gateway Module for Low-Power Wireless Communication ESP32-H2 Thread/Zigbee Gateway Module for Low-Power Wireless Communication

The ESP32-H2 Thread/Zigbee Gateway Module is a stackable development module designed for the M5 series hosts. It is based on the ESP32-H2-MINI-1 and supports Zigbee, Thread, and Matter.

linuxgizmos.com

 

[pvvx]

ESP32-H2 Thread/Zigbee Gateway Module for Low-Power Wireless Communication ESP32-H2 Thread/Zigbee Gateway Module for Low-Power Wireless Communication

The ESP32-H2 Thread/Zigbee Gateway Module is a stackable development module designed for the M5 series hosts. It is based on the ESP32-H2-MINI-1 and supports Zigbee, Thread, and Matter.

linuxgizmos.com

Там нету замеров тока потребления в режиме Zigbee router-а или просто сколько жрет ESP32-H2 в режиме приема с работающим CPUs из Flash на разных частотах.
Аналогично и там стесняются про это писать...

 

[nikolz]

обнаружил такое поведение ESP32C3 в режиме DeepSleep с заглушкой.
Время работы заглушки действительно примерно 740 мкс.
Но дальше что-то не так. ток не становится равным нулю, а составляет 6 mA.
вот такая фигня получается:

 

[pvvx]

Импульс - это включение питаний чипа и заряд кондеров.
Далее у вас спад - это кривой БП, дающий выбросы.
А площадка - это старт чипа от 13 ms, в которой он ничего не делает, а просто ждет включения и стабилизации внутренних напряжений и CLK (аппаратная фича - не программная и не исправляемая).

 

[pvvx]

Потом необходимо включить Flash, а она тоже не быстро пробуждается. Читайте errata на ESP32… c медленно пробуждающимися Flash.

@nikolz - Как я понял вы так и не прочитали то, что вам было описано про долгое пробуждение всех типов чипов после отключения питаний. В данном случае для ESP – это deep-sleep. У других чипов это обычно при первом старте питания, а в deep-sleep у них питание не снимается у критических и тормозных компонентов чипа... По этому они значительно шустрее выходят из своего deep-sleep, как ESP из легкого sleep.

Пример из SiLabs у EFR32MG13 Mighty Gecko Multi-Protocol Wireless SoC Family Data Sheet:

 

[pvvx]

Да и забудьте этот несчастный ESP32-C3. Он в простом режиме приема BLE маяков и передачи в USB-CDC греется как паровоз на ядерных отходах...

 

[nikolz]

Потом необходимо включить Flash, а она тоже не быстро пробуждается. Читайте errata на ESP32… c медленно пробуждающимися Flash.

@nikolz - Как я понял вы так и не прочитали то, что вам было описано про долгое пробуждение всех типов чипов после отключения питаний. В данном случае для ESP – это deep-sleep. У других чипов это обычно при первом старте питания, а в deep-sleep у них питание не снимается у критических и тормозных компонентов чипа... По этому они значительно шустрее выходят из своего deep-sleep, как ESP из легкого sleep.

Ну не пытайтесь Вы быть телепатом и угадывать, что другие не прочитали.
Не считайте других тупея себя.
------------------
Ваши рассуждения про то, что ESP ждет 13 ms ошибочны.
----------------------
Я выкинул из теста из документации все печати, отключил все лог журналы
Вот мой вариант теста:
---------------------------
#include "esp_sleep.h"
RTC_FAST_ATTR uint32_t s_count = 0;
RTC_FAST_ATTR uint32_t s_max_count = 20;

RTC_FAST_ATTR void wake_stub_example(void)
{ s_count++;
if (s_count >= s_max_count) {s_count = 0; esp_default_wake_deep_sleep(); return; }
esp_sleep_enable_timer_wakeup(100000);
esp_set_deep_sleep_wake_stub(&wake_stub_example);
esp_deep_sleep_start(); }

void app_main(void)
{ esp_sleep_enable_timer_wakeup(100000);
esp_set_deep_sleep_wake_stub(&wake_stub_example);
printf("Entering deep sleep\n");
esp_deep_sleep_start();
}
-------------------
а это изменение тока потребления. Масштаб по оси х - ms.

В тесте в основной программе устанавливаем режим Deepsleep
при первом выходе из режима попадаем в заглушку, которая должна вызываться при выходе из deepsleep 20 раз.
------------------
Очевидно, что участок в 5000 мка длительностью 1500 ms - это и есть многократный вызов заглушки при выходе из Deepsleep.. При последнем вызове происходит подключение флэш и полная загрузка приложения - это импульс до 25-30 мА.
----------------------
Так вот наблюдаем следующие приколы.
При работе заглушки ток потребления не становится меньше 5.4 mA и это на протяжении 1300 ms. Очевидно, что последние 300 ms - это загрузка приложения
1000 ms - это многократный вызов заглушки. Но у меня установлено 20 вызовов по 100 ms.
А по факту 10 вызовов по 100 ms. Т е в 2 раза меньше.
Если установить 10 вызовов, то получится 5.
------------------------
Теоретически на картинке должно быть 19 импульсов амплитудой 5.4ma и длительностью менее 1 ms c интервалами между ними длительностью 100 ms и амплитудой 20 мка. Один импульс с амплитудой в 25 -30 мА.
---------------
Что не так?
Просьба писать по существу данного вопроса.

 

[pvvx]

Что не так?
Просьба писать по существу данного вопроса.

У вас неадекватность в графике по шкале оси x.
Наблюдаются те-же самые 13 ms старта SoC до любого исполняемого кода после выхода из deep-sleep.

 

[pvvx]

Но у меня установлено 20 вызовов по 100 ms.
А по факту 10 вызовов по 100 ms.
Что не так?

И где-же эти 100 ms спрятались на вашем графике?

printf("Entering deep sleep\n");Время работы составляет 20*10/115200 = 1.7 ms и это наверно импульс в конце вашего графика

 

[pvvx]

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

 

[nikolz]

И где-же эти 100 ms спрятались на вашем графике?

printf("Entering deep sleep\n");Время работы составляет 20*10/115200 = 1.7 ms и это наверно импульс в конце вашего графика

посмотрите внимательно на график. Уровень 5.5 mA начинается с момента 100 ms , а заканчивается в 1405 ms.
теперь вычитаем из 1400 100 получаем 1400 ms Это 14 раз по 100 ms.
Понимаешь, Михалыч, вот в этих 1400 ms и спрятались 100 ms 10 раз.

 

[nikolz]

pvvx,
Специально для вас тест без вывода на печать:

#include "esp_sleep.h"
void wake_stub_example(void);
void app_main(void)
{ esp_sleep_enable_timer_wakeup(100000);
esp_set_deep_sleep_wake_stub(&wake_stub_example);
// printf("Entering deep sleep\n");
esp_deep_sleep_start();
}


Что не так?

 

[nikolz]

А вот еще один прикол.
Выполнил тест из примеров разработчика.
и получил такую хрень: