Arduino и прочие питомцы

Не успел я огорчиться, что давно анонсированный и все никак не выходящий в свет МК от Espressif ESP32-C6 не смотря на поддержку WiFi6 будет работать только на частоте WiFi 2.4 ГГц (и зачем он тогда такой нужен?), как Эспрессивы исправились и анонсировали ESP32-C5 с поддержкой WiFi6 на обоих диапазонах частот 2.4 ГГц и 5 ГГц. Ну что же, теперь будем ждать его. :) Ссылка на новость

А теперь сравним потребление разных ULP ядер в МК ESP32-S2 (пока вы копите лайки под предыдущей статьей для статьи о раннем пробуждении :)). Возьмем условно одинаковую программу для ULP ядра, которая при нажатии на кнопку, замыкающую GPIO0 на землю не менее 50 мс., увеличивает счетчик нажатий и будит микроконтроллер. Тот весело мигает светодиодом (в коде GPIO светодиода задан константой LED_PIN), пишет количество нажатий кнопки и уходит в глубокий сон. ULP ядро запускается таймером, измерения потребления проводились для значений таймера в 1, 3, 5, 10 и 20 мс. Код для FSM ULP ядра на данный момент можно откомпиллировать только в девелоперской версии ESP-IDF, код же для RISC-V ULP ядра напротив не работает в девелоперской версии ESP-IDF, зато работает в релизе 4.4.1. Вариантов использовать для сборки Arduino нет, только ESP-IDF, увы. Итак, перейдем к результатам: ULP-FSM 1 ms 80 uA 3 ms 60 uA 5 ms 50 uA 10 ms 35 uA 20 ms 30 uA ULP-RISCV 1 ms - 3 ms 70 uA 5 ms 60 uA 10 ms 40 uA 20 ms 30 uA При значении таймера в 1 мс. для RISC-V ULP ядра, основной МК просыпался от срабатывания ловушки на ULP ядре, т.е. можно считать этот вариант неработоспособным. Как видим, старое FSM ULP ядро чуть энергоэффективнее нового RISC-V, хотя писать для него в разы сложнее. С другой стороны, достаточно сложный код для RISC-V иногда выпадает в ловушку, так что FSM может быть надежнее. Но решать только разработчику по результатам собственного тестирования. Т.е. вам.

Так сколько же все-таки потребляет ESP32 (тот самый обычный ESP32 с двумя ядрами и FSM ULP ядром) на примере готового модуля ESP32-S при питании от 3.3 В в различных режимах сна? Скетч полагается на то, что кнопка коммутирует на землю изначально подтянутый к питанию GPIO0, а светодиод катодом подключен к GPIO2. Первые 5 сек. работы скетча CPU активен, далее 5 сек. CPU в режиме легкого сна, далее легкий сон с пробуждением от нажатия на кнопку, далее 5 сек. глубокого сна, далее глубокий сон с мониторингом кнопки EXT0, далее глубокий сон с мониторингом кнопки EXT1 и наконец глубокий сон с мониторингом кнопки с помощью ULP каждые 5 мс. CPU Active 38 mA CPU Light Sleep (timer) 1560 uA CPU Light Sleep (GPIO) 1560 uA CPU Deep Sleep (timer) 3 uA CPU Deep Sleep (EXT0) 4 uA CPU Deep Sleep (EXT1) 4 uA CPU Deep Sleep (ULP each 5 ms) 20 uA Само собой, это потребление с выключенными WiFi и BT. Если для ULP уменьшить время таймера с 5 мс, то потребление энергии возрастет, зато станет возможным отслеживать кратковременные изменения состояния RTC GPIO. Потребление же ULP в режиме постоянного мониторинга в глубоком сне основных ядер составляет 435 uA (для этого в скетче необходимо раскомментировать дефайн ULP_INFINITE). Скетч сделан для Arduino IDE, хотя от фреймворка Arduino используется только вывод в UART через объект Serial, для остального используется ESP-IDF. Если это будет интересно хотя бы 1/10 подписчиков, то напишу статью о том, как использовать раннее просыпание...

Сейчас ковыряюсь с ESP32-S2 в виде готового модуля ESP-12H (видео о нем есть на канале), а конкретно с ULP (Ultra Low Power) ядрами (там их два, правда использовать можно только одно на выбор: "старое" чуть обновленное FSM (конечный автомат) и новое RISC-V). Если вы не знали, ULP ядро создано не только для работы в глубоком сне основного ядра МК, оно может работать постоянно параллельно с основным и обмениваться с ним данными, расположенными в RTC памяти. Конечно же использовать новое RISC-V ULP ядро в разы проще! Писать код для него можно на C (а не только на ассемблере), есть 32 32-х битных регистра, поддерживается целочисленное умножение/деление, доступ к переменным существенно проще на уровне исходного кода. Только пока нет поддержки для Arduino, но это не особо большая проблема, если использовать ESP-IDF и Arduino as component, например. FSM ULP ядро лишь чуть обновилось со времен ESP32. Все те же 4 16-ти битных регистра, ограниченный ассемблер или макросы для C. Правда с помощью макросов это ядро можно использовать для Arduino, но на данный момент поддержка Arduino собрана без резервирования памяти под ULP программу, да и FSM ULP ESP32-S2 поддерживается только в девелоперской версии ESP-IDF, релиз 4.4.1 этим не озаботился. А насколько же ULP эти ядра? Можно ли их использовать постоянно, пока основное ядро МК будет в глубоком сне? Не по ULP таймеру, а именно в вечном цикле? Около 300 мкА для RISC-V и 180 мкА для FSM. Т.е. не очень-то и ULP...

Поддержка Яндекса - это, конечно, "что-то"... :) Пытаюсь "причесать" проект, использующий Yandex IoT Core (MQTT брокер Яндекса) для накопления информации с датчиков температуры/влажности. В качестве БД решил использовать Yandex Database (бессерверное распределенное хранилище), данные в которую попадают благодаря триггерам IoT Core (еще одна бессерверная технология). Данные прекрасно собираются, и об этом можно было бы уже написать статью или снять ролик, но... Но при обработке данных с помощью Yandex DataLens обнаружил две проблемы, которые портят всю простоту реализации. Завел тикеты в ТП Яндекса, далее смотрите первую фразу... :) Итак, ждать (не)вероятного исправления проблем или поделиться тем что есть сейчас?

Итак, эксперимент по проверке точности длительности глубокого сна МК ESP-C3 с применением внешнего кварца на 32768 Гц завершен. Получены следующие результаты (в секундах): Время Отклонение 3600 -0,009 7200 -0,162 14400 2,289 28800 -0,772 43200 -1,108 86400 0,318 Т.е. на сутках отклонение не превысило и полсекунды, правда и стабильности особой не наблюдается (аномалия на 14400). Хотя по сравнению с использованием внутреннего источника тактирования, прогресс налицо. Для ESP-C3 внешний кварц надо подключать к GPIO0 и GPIO1, для других серий ESP32 нужные пины вы можете посмотреть в даташитах на МК. После кварца надо ставить конденсаторы малой емкости на землю для стабилизации кварца (я использовал на 22 pF). Осталось найти способ с наименьшими усилиями применить этот метод при использовании фреймворка Arduino. Пока использовал ESP-IDF и правил параметры проекта. Как найду решение - опубликую.

Учитывая переход моего канала с youtube на Yandex.Zen, может быть далее делать контент преимущественно в формате текстов с картинками, а не видеороликов с экранами и болтовней? Для съемок видеороликов мне нужно больше времени, которое я лучше уделю дочери и подругам. :) И говорить долго мне затруднительно в связи с перенесенным на ногах <private-info>, а особенно потом слушать жЫвотных (ой, простите, справедливых критиков, конечно :) ), которых мой прононс раздражает... В данном случае я прошу вас высказать свое мнение в комментариях. Спасибо!

Если вы использовали режим глубокого сна на ESP8266/ESP32 всех мастей, то не могли не заметить дрифт реальной длительности сна. Дело в том, что внутренний источник тактирования является весьма неточным, за несколько часов разбег может составить от десятков секунд до нескольких минут! Что же делать? Использовать внешние часы реального времени? Хороший вариант, но добавит собственное потребление к потреблению МК во сне. Благо ESP32 имеют возможность использовать для внутренних RTC внешний кварц на 32КГц. Сейчас идет эксперимент по проверке точности длительности глубокого сна на ESP32-C3 с внешним кварцем на 32768 Гц. Пока результаты обнадеживающие, хотя точность все-таки +- одна-две секунды. Проблема этого решения состоит в том, что чтобы использовать иной источник тактирования RTC, необходимо перекомпилировать поддержку Arduino с измененными параметрами, сменить источник "на ходу" не получается. Этой проблемы нет при непосредственном использовании ESP-IDF. Результаты эксперимента будут обнародованы через пару дней...