Экономим энергию на ESP32-P4: эксперименты с Light‑sleep, Deep‑sleep и периферией CrowPanel

Последнее время всё чаще сталкиваюсь в HMI проектах с панелями на базе ESP32-P4, и это довольно удобно: экран подключен, сенсор работает, связь есть. Можно сразу же делать интерфейс и приложение. В один момент появилась задача обеспечить работоспособность CrowPanel (Elecrow) от батареи, и началось интересное.

Замер мультиметром показал около 600 мА потребления панели при яркости 60%. Если грубо прикинуть, то на аккумуляторе 1000 мАч будет меньше 2 часов.

Хотелось бы больше, поэтому решил разобраться, что можно сделать: понизить частоту, выключить подсветку и периферию, отправить Р4 в сон. Заодно выяснить, где заканчиваются возможности прошивки, и начинается схемотехника.

Забегая вперед: в одном из проверенных сценариев ток удалось снизить с 335,9 до 96,7 мА, на 71,2%. Потом на существенно модифицированной плате получилось увидеть и 6,5 мА. Но это уже отдельный исследовательский эксперимент, а не готовый режим с пробуждением по касанию. Ниже — как я до этих цифр дошёл и что из них можно применить на практике.

Железо и измерительный стенд

CrowPanel Advanced 7" ESP32-P4 HMI, ESP32-P4 ревизии 1.3.

Основные узлы тестируемой панели приведены ниже. Это краткий обзор аппаратной платформы; далее подробнее рассмотрю только те подсистемы, которые имеют значение для нашей задачи.

Для подробностей можно обратиться к материалам Elecrow и схеме платы, а характеристики самого микроконтроллера приведены в даташите ESP32-P4 ревизии 1.3.

Для измерения тока использовался Nordic Power Profiler Kit II (PPK2) в режиме Source Meter с установленным напряжением 4,0 В.

PPK2 подключался вместо аккумулятора; других источников питания при измерениях не было. Таким образом, регистрировался входной ток всей платы, а не отдельно ESP32-P4. Частота сбора данных составляла 100 Гц.

Программная платформа — ESP‑IDF v6.1.

Методика измерений

Во всех основных экспериментах использовался один и тот же протокол: два последовательных цикла в рамках одной записи, каждый из которых включал заданную последовательность состояний. Продолжительность каждой фазы составляла около 30 секунд. Исключением был тест последовательного отключения периферии: его начальная фаза Normal длилась 15 секунд, поскольку после этого интервала GT911 автоматически переходил в режим Green; остальные фазы длились примерно по 30 секунд. Средний ток рассчитывался по установившемуся участку каждой фазы, без учёта переходных процессов.

Какие механизмы предоставляет ESP32‑P4

ESP32-P4 включает два высокопроизводительных ядра RISC‑V (HP), на которых работает FreeRTOS, и отдельное малопотребляющее ядро (LP или ULP coprocessor). Последнее может выполнять небольшую программу и взаимодействовать с периферией LP‑домена, в том числе пока HP‑система спит. Для нашей задачи наиболее интересны три механизма:

Ниже — только те особенности этих механизмов, которые оказались существенными для экспериментов. Подробные настройки и ограничения описаны в документации ESP‑IDF: Power Management и Sleep Modes.

DFS — динамическое изменение частоты CPU/APB

Во время работы приложения ESP‑IDF может динамически изменять частоты CPU и APB. Для исследуемой ревизии 1.3 может быть использован только диапазон 40–360 МГц из‑за ограничения на максимальную частоту. Частота APB зависит от частоты CPU и меняется вместе с ней. Управление частотами осуществляется через настройки Power Management и механизм PM locks. Приложение и драйверы могут захватывать блокировки, ограничивая работу алгоритма DFS, например требуя максимальной частоты CPU или запрещая автоматический переход в Light‑sleep.

Для сравнения можно обратиться к таблице 5–7 «Current Consumption in Active mode» (раздел 5.6 «Current Consumption in Active and Low‑power Modes») даташита ESP32-P4 ревизии 1.3. В ней приводятся характеристики самого кристалла при заданных условиях, без учёта всей внешней схемы нашей платы.

Режимы сна

Light‑sleep сохраняет контекст HP‑системы, поэтому после пробуждения приложение может продолжить свое выполнение с момента остановки. В Deep‑sleep большая часть HP‑системы выключается; после пробуждения требуется повторная загрузка приложения. По сути это почти то же самое, что сделать перезагрузку. Это снижает потребление, но увеличивает время возвращения в рабочее состояние. Оба режима допускают настройку источников пробуждения, однако для Deep‑sleep подходят только GPIO из LP домена (VDD_LP). Возможности удержания состояний GPIO также зависят от ревизии кристалла.

Для оценки потенциальной экономии полезно сравнить типовые значения тока самого SoC из таблиц 5–8 «Current Consumption in Low‑Power Modes» (раздел 5.6 «Current Consumption in Active and Low‑power Modes») даташитов ESP32-P4 ревизии 1.3 и новой ревизии:

Здесь приведён ток самого ESP32-P4 при определённых тестовых условиях, а не ток всей HMI‑платы. Эти значения нельзя напрямую сопоставлять с измерениями всей схемы. Изменения между ревизиями кристалла описаны отдельно в руководстве для ESP32-P4 v3.x.

API ESP‑IDF позволяет выбрать режим сна и настроить источники пробуждения.

Light‑sleep в автоматическом режиме использует механизм FreeRTOS tickless idle: когда потоки заблокированы в ожидании событий и у планировщика нет готовой работы, система может установить таймер пробуждения и временно перейти в сон. В принципе, такой подход применим и к приложению с LVGL. Однако в нашем случае драйвер DSI удерживает блокировку, запрещающую автоматический Light‑sleep. Пока соответствующий драйвер инициализирован и блокировка активна, переход в сон не происходит.

В зависимости от режима доступны разные источники пробуждения: таймер, GPIO, LP/ULP‑подсистема и другие. Их перечень и ограничения приведены в разделе документации Wakeup Sources.

Панель с включённым экраном

HMI‑панель оснащена ЖК‑дисплеем с разрешением 1024 × 600 пикселей и сенсорным контроллером GT911. Контроллер дисплея — EK79007. Изображение передаётся по MIPI DSI, а информация о касаниях поступает от GT911 по I2C.

ESP32-P4 выполняет приложение и формирует кадры, которые встроенный DSI‑контроллер передаёт на дисплей. MIPI DSI — последовательный интерфейс передачи данных на дисплей. Команды и параметры контроллера передаются через интерфейс DBI поверх DSI, а поток изображения — через DPI поверх DSI. Яркость подсветки регулируется ШИМ‑сигналом, формируемым периферийным модулем LEDC.

На программном уровне используются драйверы ESP‑IDF для MIPI DSI, esp_lcd, I2C, GPIO и LEDC. На следующем уровне работает LVGL, отвечающая за пользовательский интерфейс. Два кадровых буфера (framebuffers) размещены во внешней PSRAM. Для такого размера экрана не представляется возможным разместить эти буферы во внутренней памяти. При переходе в спящий режим (Light‑sleep), PSRAM переводится в режим Half‑sleep с сохранением данных. В этом состоянии обычный доступ к кадровым буферам недоступен, поэтому передача изображения и отрисовка должны быть остановлены до перехода в сон.

Во время штатной работы поток LVGL периодически активируется для обработки таймеров и проверки областей интерфейса, требующих перерисовки. Обработка касаний построена на событиях: прерывание от GT911 пробуждает поток LVGL, поэтому непрерывно опрашивать контроллер по I2C не требуется.

При этом передача изображения продолжается и при отсутствии изменений в интерфейсе. При инициализации DPI‑драйвер запускает DMA и видеорежим DSI. После завершения передачи кадрового буфера DMA запускается вновь, даже если LVGL не подготовила новый кадр. В результате изображение постоянно считывается из PSRAM и передаётся по DSI: при отсутствии изменений повторяется прежний кадр, а при перерисовке LVGL обновляет свободный буфер и переключает активный.

Такая работа дисплейного тракта сама по себе ограничивает возможности перехода в кратковременный сон. Но решающим препятствием оказывается блокировка управления питанием: DSI PHY удерживает ESP_PM_NO_LIGHT_SLEEP на протяжении работы шины, а DPI‑драйвер дополнительно использует ESP_PM_CPU_FREQ_MAX. Поэтому при работающем дисплее автоматический Light‑sleep недоступен.

Остальная периферия

Помимо дисплея на плате могут использоваться другие периферийные узлы:

• MIPI CSI — интерфейс камеры, не задействованный в нашем сценарии;

• ESP32-C6 — отдельная микросхема для беспроводной связи, поскольку ESP32-P4 не имеет собственного радиомодуля; P4 может управлять сигналом её включения C6_EN;

• аудиотракт — PDM‑микрофон и усилители динамиков;

• STC8 — вспомогательный контроллер, связанный с питанием и индикацией;

• CH340K — преобразователь USB‑UART;

• внешние устройства, которые могут подключаться к доступным GPIO через I2C, SPI, UART и другие интерфейсы.

То есть когда ESP32-P4 решает перейти в один из энергосберегающих режимов, он должен корректно управлять еще и периферией и по возможности либо выключать ее, либо переводить в соответствующий режим энергосбережения.

Панель в ожидании касания

Для данного типа устройств кажется естественным такой сценарий энергосбережения — переход в режим ожидания после периода бездействия. Для пользователя это выглядит просто: экран гаснет, а панель остаётся в экономичном состоянии до следующего касания.

В нашей реализации сначала отключается периферия, которой ESP32-P4 может управлять через GPIO. Затем выключается подсветка, останавливаются драйверы вывода изображения, а контроллер дисплея переводится в спящий режим либо удерживается в ресете через вывод LCD_RESET. GT911 переводится в режим Green, в котором он продолжает регистрировать касания и может формировать прерывание. Этот сигнал используется как источник пробуждения ESP32-P4 из Light‑sleep. Для управляющих GPIO необходимо сохранять уровни, удерживающие отключённую периферию в нужном состоянии.

В принципе, здесь можно рассматривать и Deep‑sleep. Однако установленный ESP32-P4 ревизии 1.3 имеет ограничения на удержание состояний GPIO в Deep‑sleep; к тому же, выбор источников пробуждения в этом режиме ограничен выводами LP‑домена. К этим ограничениям мы вернёмся позже.

Что показали измерения

Начну с замера, который был ближе всего к исходной задаче: что произойдёт, если экран погасить, остановить дисплейный тракт и перевести систему в Light‑sleep. Именно такой режим я хотел использовать между касаниями.

Замеры для сценария с ожиданием касания

В этом эксперименте Ready — исходное рабочее состояние приложения с включённым экраном и яркостью подсветки 20%. На экране непрерывно воспроизводилась анимация кругового слайдера, создававшая небольшую нагрузку на CPU. Это состояние использовалось как исходное для сравнения с Light‑sleep. Перед переходом в сон деинициализировался весь дисплейный тракт, через GPIO отключались доступные периферийные узлы, включая ESP32-C6 и усилители динамиков. Контроллер LCD удерживался в состоянии сброса через LCD_RESET, однако питание его цепей при этом сохранялось. Подсветка также выключалась.

В использованной конфигурации ESP‑IDF 6.1.0 были включены CONFIG_PM_SLP_SPIRAM_HALFSLEEP_ENABLED и CONFIG_ESP_SLEEP_SET_FLASH_DPD. При переходе в Light‑sleep PSRAM автоматически переводилась в режим Half‑sleep с сохранением данных, а микросхема флеш‑памяти W25Q128JVSIQ — в режим Deep Power‑Down. После пробуждения ESP‑IDF возвращала обе микросхемы в рабочее состояние.

Последовательность Ready — Light‑sleep повторялась в двух циклах c фазами по 30 секунд.

Переход из Ready в Light‑sleep вместе с программным отключением доступной периферии уменьшил средний ток на 239,2 мА (71,2%). Эта разница характеризует эффект целого набора действий, поэтому приписать её только дисплею или самому режиму сна нельзя.

Опция CONFIG_PM_POWER_DOWN_PERIPHERAL_IN_LIGHT_SLEEP позволяет ESP‑IDF отключать цифровой периферийный домен во время Light‑sleep при соблюдении ограничений со стороны используемых драйверов.

Наблюдавшаяся разница составляла около 0,2 мА. На фоне высокого потребления всей платы и при отсутствии оценки повторяемости этого недостаточно для уверенного количественного вывода.

Вариант с Deep‑sleep

В Deep‑sleep основная цифровая периферия выключена, поэтому обычный GPIO‑контроллер не может обрабатывать прерывания так же, как при активной работе.

Для пробуждения по внешнему сигналу используется логика LP‑домена. На ESP32-P4 источниками такого пробуждения могут служить только GPIO, питающиеся от VDD_LP (в частности, группа GPIO0-GPIO15).

На исследуемой плате линия INT_TP контроллера GT911 подключена к GPIO42, который не относится к этой группе. Поэтому сигнал прерывания сенсорного контроллера нельзя непосредственно использовать для пробуждения из Deep‑sleep.

Кроме того, на ESP32-P4 ревизии 1.3 отсутствует необходимая нам возможность надёжно сохранять состояния обычных HP GPIO на всём протяжении Deep‑sleep и последующего пробуждения. Для этой платы это существенно: часть периферии остаётся выключенной только пока управляющие выводы удерживают определённый уровень. А после перехода в Deep‑sleep они снова включаются, что приводит к увеличению потребления. В следующем эксперименте будет видно, какое влияние могут оказывать элементы периферии. В ревизии ESP32-P4 v3.x была добавлена полноценная поддержка удержания выводов в Deep‑sleep.

Дополнительно повторил предыдущий эксперимент с ожиданием касания, заменив Light‑sleep на Deep‑sleep и настроив пробуждение по таймеру. При аналогичной подготовке периферии средний ток составил около 139,3 мА, тогда как в Light‑sleep он составлял около 96,7 мА.

Теперь — ещё один способ экономии, который обычно приходит в голову довольно быстро: уменьшить частоту процессора. Мне было интересно проверить его отдельно и посмотреть, будет ли от этого заметная польза, когда работает уже не синтетический тест, а интерфейс с дисплеем.

Влияние частоты CPU

Синтетический тест

В этом эксперименте оценивалось влияние частоты CPU на ток всей платы при двух состояниях нагрузки — Busy и Idle — и двух частотах, минимальной и максимальной. Для нашего экземпляра ESP32-P4 ревизии 1.3 использовались 40 и 360 МГц соответственно.

Программный стек дисплея не инициализировался, сам контроллер LCD удерживался в ресете. Вся периферия, которую можно было отключить программно через GPIO, была выключена: C6 через C6_EN, усилители динамиков через AUDIO_OUT_SD и подсветка экрана через LCD_BK_EN.

Состояния нагрузки определялись следующим образом:

Busy: основной поток непрерывно выполнял синтетическую нагрузку с обращениями к volatile‑памяти и целочисленными операциями, чтобы компилятор не соптимизировал эти вычисления.

Idle: основной поток заблокирован, поэтому исполнялся Idle поток из FreeRTOS. Явный переход в Light‑sleep не выполнялся.

Каждое состояние удерживалось примерно 30 секунд. Последовательность Busy @ max — Idle @ max — Busy @ min — Idle @ min выполнялась в двух циклах в одной непрерывной записи.

Снижение частоты с 360 до 40 МГц уменьшило измеренный средний ток на 29,5 мА (19,7%) в состоянии Busy и на 20,6 мА (15,2%) в состоянии Idle.

Эти результаты демонстрируют влияние принудительного выбора частоты CPU на ток в заданных условиях, но не позволяют оценить энергетическую эффективность выполнения полезной работы, так как на более низкой частоте одна и та же работа может потребовать больше времени.

Минимальная частота в работающем приложении

В дополнительном эксперименте частота CPU принудительно снижалась до 40 МГц при обычном состоянии Ready: включённый дисплей, анимация интерфейса и яркость подсветки 20%. Было записано два цикла с фазами продолжительностью около 30 секунд каждая.

Непосредственно после снижения частоты ток уменьшался лишь на 2–4 мА (около 1% от общего потребления). При этом за две минуты записи наблюдался восходящий дрейф тока приблизительно на 1 мА, что затрудняет сравнение средних значений без поправки на дрейф.

Важно другое: при работе на 40 МГц изображение повреждалось (появлялся синий экран), а драйвер DSI сообщал об ошибке can't fetch data from external memory fast enough, underrun happens. Такое поведение согласуется с недостаточной эффективной пропускной способностью при чтении кадрового буфера из PSRAM, хотя точный вклад изменения частот CPU и APB не был установлен.

Промежуточные частоты и другие варианты размещения кадровых буферов не проверялись. С учётом небольшого наблюдаемого выигрыша и нарушения работы дисплея конфигурация с 40 МГц была признана непригодной для практического использования на этой плате. Дальнейшее исследование этого направления было прекращено.

После этого я решил измерить эффект от отключения периферии по шагам. Не просто сравнить две крайние точки, а посмотреть, что происходит с током после каждого действия: перевода сенсора в экономичный режим, отключения ESP32-C6, сброса контроллера дисплея и перехода ESP32-P4 в Light‑sleep.

Сколько потребляет периферия

Чтобы оценить эффект программного управления периферией и перехода ESP32-P4 в Light‑sleep, были записаны два цикла с шестью последовательными состояниями в каждом. Начальная фаза Normal представляла собой исходную точку для сравнения с последующими отключениями модулей. Она длилась 15 секунд — максимальная задаваемая длина интервала бездействия до автоматического перехода GT911 в режим Green. Остальные фазы длились примерно по 30 секунд.

Последовательно применялись следующие действия:

1. Normal: исходная конфигурация периферии без последовательных энергосберегающих действий, GT911 в обычном режиме. Подсветка экрана выключена.

2. GT911 Green: автоматический переход сенсорного контроллера в режим с пониженной частотой сканирования.

3. GT911 Sleep: программный перевод GT911 в режим сна.

4. C6 disabled: отключение ESP32-C6 низким уровнем на C6_EN (GPIO32).

5. LCD reset: перевод LCD_RESET (GPIO41) в низкий уровень при сохранении предыдущих состояний периферии.

6. ESP32-P4 Light‑sleep: переход ESP32-P4 в Light‑sleep с сохранением заданной конфигурации периферии.

Средний ток каждой фазы рассчитывался по установившемуся участку, без переходных процессов. Для Normal использовалось окно 8 секунд, для остальных состояний — 20 секунд.

Последовательное переключение состояний периферии снизило средний ток с 181,6 до 122,0 мА, то есть на 59,6 мА. Переход ESP32-P4 в Light‑sleep дополнительно уменьшил ток на 24,8 мА, до 97,2 мА. Суммарное снижение относительно Normal составило 84,4 мА (46,5%).

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

Существенное ограничение еще состоит в том, что GT911 в режиме Sleep перестаёт штатно регистрировать касания, поэтому для пробуждения потребовался бы другой источник. Для нашего сценария пробуждения по касанию перевод GT911 в Sleep непригоден. Поэтому соответствующее снижение тока на 4,0 мА (разница между фазами Green и Sleep) нельзя учитывать как доступную экономию без изменения способа пробуждения. При этом измерения последующих фаз проводились уже с GT911 в состоянии Sleep, и их значения нельзя без дополнительной проверки напрямую переносить на сценарий с работающим сенсором.

Даже после всех программных действий оставались десятки миллиампер. Поэтому следующим шагом стала сама плата: какие цепи продолжают получать питание и что изменится, если отключить их физически, а не только остановить драйвер.

Эксперименты с аппаратным отключением питания периферии

Чтобы исследовать остаточное потребление, которое не удавалось устранить программным управлением периферией, провёл серию экспериментов с физическим отключением отдельных цепей питания.

В таблице сопоставлены две конфигурации: с отсоединёнными шлейфами LCD и тач сенсора, а также с дополнительно выключенным преобразователем (U16, MT3608), который управляет схемой LCD bias. Для отключения U16 его вход разрешения удерживался в низком уровне через внешний резистор 1 кОм. В каждом случае записывались два цикла с фазами Ready и Light‑sleep продолжительностью около 30 секунд. Средний ток вычислялся по установившимся 20-секундным участкам.

Здесь тоже программный стек дисплея не инициализировался. Вся периферия, которую можно было отключить программно через GPIO, была выключена: C6 через C6_EN, усилители динамиков через AUDIO_OUT_SD и подсветка экрана через LCD_BK_EN. Ready соответствует исходному состоянию.

Дополнительное отключение U16 при отсоединённых шлейфах уменьшило средний ток на 70,5 мА в Ready и на 69,4 мА в Light‑sleep.

Столь существенная разница показывает, что цепь формирования напряжений смещения LCD (LCD bias) оставалась заметным потребителем даже при физически отключённых дисплее и тач сенсоре. При этом измеренная разность относится ко всей отключённой цепи, а не только к собственному току покоя микросхемы MT3608.

Это объясняет, почему мы в эксперименте с ожиданием касания наблюдали такое большое значение тока, несмотря на спящий режим и программное отключение дисплейной подсистемы.

Расширенная аппаратная изоляция цепей питания

Следующий эксперимент включал уже более масштабную модификацию платы. В итоговой конфигурации средний ток в Light‑sleep составил 6,5 мА. Это значение было получено усреднением одного 30-секундного интервала, без повторных циклов.

Для достижения этой конфигурации были выполнены следующие аппаратные изменения:

• На управляющие входы IC2, IC3, IC7, IC8 и U16 установлены подтягивающие к земле резисторы номиналом 1 кОм. Это переводило соответствующие входы разрешения питания (CE/EN) в низкий уровень и отключало питаемые ими узлы.

• Такой же резистор 1 кОм установлен на линию C6_EN, чтобы удерживать ESP32-C6 в выключенном состоянии.

• Удалена перемычка R65 номиналом 0 Ом для отключения линии питания LCD_VDD.

• Удалены резисторы R189 и R188, через которые сохранялась возможность паразитного питания STC8 по линиям I2C SDA и SCL при выключенном IC8.

• Отсоединены шлейфы FPC3 и J21.

Линия LCD_VDD питает как LCD‑панель, так и тач сенсор. На схеме предусмотрено посадочное место под регулятор IC4, указанный как неустановленный (NC), а также перемычка R65. Удаление R65 разрывало общую цепь питания LCD и тач сенсора. При этом выходы преобразователя смещения LCD оставались отдельными цепями, поэтому U16 также требовалось отключить.

Контроллер STC8 получает питание через регулятор IC8 и работает под управлением собственной прошивки. STC8 тоже имеет спящий режим, но команда включения этого режима отсутствует в реализации протокола управления по I2C, а исходный код заводской прошивки STC8 не был доступен. Поэтому в эксперименте его питание отключалось через IC8. Удаление R189 и R188 дополнительно устраняло паразитное питание через сигнальные линии I2C.

По оценке, внешние цепи с шестью подтягивающими резисторами добавляли к измеренному току приблизительно 1,5–1,8 мА, но отдельно этот вклад не измерялся.

Полученный результат показывает, что при физическом отключении нескольких постоянно запитанных узлов остаточный ток платы можно снизить до единиц миллиампер. Однако это наблюдение в существенно модифицированной конфигурации, а не измерение тока одного ESP32-P4. Оно также не означает, что такой режим без дополнительных изменений пригоден для штатного пробуждения по касанию.

Здесь важно не смешивать две вещи. Снижение до 6,5 мА показывает, какой запас есть у аппаратной оптимизации. Но в этом опыте часть цепей была отключена физически, а шлейфы отсоединены. Для устройства, которое должно самостоятельно просыпаться от касания и сразу возвращаться к интерфейсу, понадобится другая конфигурация питания.

Ограничения при питании от аккумулятора

При питании от аккумулятора или измерительного модуля PPK2 на исследуемой плате периодически наблюдались перезагрузки по brownout при повышении яркости подсветки. При питании от USB проблема не воспроизводилась. Нестабильность наблюдалась на разных значениях яркости, поэтому в экспериментах использовалось консервативное значение яркости в 20%. Причина проблемы систематически не исследовалась.

Что в итоге получилось

Если вернуться к начальной задаче, самый полезный результат получился при переходе в Light‑sleep с предварительной остановкой дисплея и отключением доступной периферии. Ток всей панели в измеренной конфигурации снизился на 71,2%. Это не результат одной волшебной настройки ESP‑IDF: пришлось разбираться с работой дисплейного тракта и последовательностью отключения устройств.

Эксперименты показали, что ESP32-P4 предоставляет несколько механизмов управления энергопотреблением, но их эффективность на готовой HMI‑плате зависит не только от настроек микроконтроллера. Существенную роль играют дисплейный стек, периферийные устройства и схема распределения питания.

Отдельные модули уже допускают частичное управление. ESP32-C6 можно отключать через C6_EN, соединённый с его CHIP_PU. Усилители динамиков можно переводить в Shutdown. Подсветку можно выключить через LCD_BK_EN. При остановке тактирования цифрового интерфейса микрофонов их активность снижается, но собственное потребление аудиоцепей и стабилизаторов без отдельного отключения питания не обязательно становится нулевым.

Эксперименты подтвердили значимость постоянно запитанных узлов. После расширенной аппаратной изоляции нескольких цепей средний ток платы в Light‑sleep удалось снизить до 6,5 мА. Это показывает, что без постоянно запитанных периферийных узлов потребление всей платы может составлять единицы миллиампер, хотя оно по‑прежнему превышает типовые значения для отдельного ESP32-P4 из даташита. Однако эта конфигурация включала физические доработки и отсоединение шлейфов, поэтому результат нельзя считать достижимым штатными настройками прошивки или прямо переносить на полноценное устройство с пробуждением по касанию.

Главный практический вывод состоит в том, что возможности энергосбережения закладываются не только в прошивке, но и на этапе проектирования питания устройства.

Для меня CrowPanel в этой истории — прежде всего готовая платформа, на которой можно быстро запустить интерфейс, подключить нужную периферию и проверить приложение на настоящем устройстве. А результаты этого опыта хорошо показывают, почему при разработке HMI полезно смотреть на питание всей системы, а не только на цифры из даташита микроконтроллера.

Когда питание сетевое, одни параметры выходят на первый план. Когда устройство должно долго жить от аккумулятора и просыпаться по касанию — другие. Теперь у меня есть реальные замеры, от которых можно отталкиваться в следующем проекте.

Результаты можно использовать уже на текущей ревизии панели. Один из первых шагов — управлять подсветкой: выбирать достаточную для работы яркость и вовсе выключать её, когда экран не нужен.

Для длительного ожидания можно применить проверенный нами сценарий: остановить дисплейный стек, отключить доступную для управления периферию и перевести ESP32-P4 в Light‑sleep с пробуждением по касанию. Постоянно запитанные цепи ограничивают достигаемую экономию, но эти меры уже позволяют значительно сократить потребление без доработки платы.

При проектировании платы энергосберегающие сценарии стоит закладывать заранее: предусматривать отключение ненужных узлов и работу источников пробуждения, а потребление в этих состояниях проверять уже на раннем прототипе, вместе с основной функциональностью устройства.