Обзор энергосберегающего проектирования¶

Назначение и аудитория руководства¶

Это руководство посвящено практическому снижению энергопотребления устройств на SF32: режимам питания, реальным причинам разряда аккумулятора и организации прошивки, при которой система как можно дольше остаётся в режиме низкого энергопотребления. Энергопотребление определяется системой в целом. Решения по Bluetooth, графике, аудио и ИИ напрямую влияют на автономность, поэтому в руководстве эти факторы рассматриваются совместно.

В документации SDK от SiFli описан основанный на RT-Thread слой промежуточного ПО управления питанием (PM) для отдельных целевых устройств, включая SF32LB52x. Доступные режимы и поведение при пробуждении могут различаться в зависимости от устройства и конфигурации SDK; сверяйтесь с документацией конкретного устройства. В семействах, где SDK распределяет задачи Bluetooth-контроллера на отдельный процессор (см. Bluetooth-процессор), отдельный процессор может обрабатывать радиособытия без пробуждения CPU приложения при каждом событии. Возможность CPU приложения оставаться в режиме сна зависит от распределения задач, настроенных источников пробуждения и межпроцессорного обмена; это нужно проверить на целевом устройстве.

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

Сначала определите энергетический бюджет изделия¶

До написания кода управления питанием задайте требования к изделию:

• Целевую автономность в часах, днях или неделях и ёмкость аккумулятора.
• Ожидаемую долю времени в каждом состоянии: активное использование, ожидание при подключении и полный сон.
• События, которые должны пробуждать систему, и допустимое время реакции.
• Подсистемы, которые должны работать постоянно, например соединение Bluetooth, постоянно включённый дисплей или голосовая активация, и подсистемы, которым достаточно включаться по событию.
• Поведение при зарядке и ожидаемое число циклов зарядки, если они важны для политики питания изделия.

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

Режимы питания и инфраструктура PM¶

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

Во время работы система переходит из одного состояния в другое. Настроенный источник пробуждения выводит CPU или подсистему из режима низкого энергопотребления; последовательность пробуждения и восстановления тактирования зависит от устройства. После завершения задачи ответственные драйверы или задачи должны снять запросы PM, блокирующие сон, чтобы настроенная политика могла выбрать допустимый режим низкого энергопотребления. Осциллограмма ниже показывает только относительные переходы, а не токи и временные интервалы конкретного устройства.

Диаграмма: переходы между режимами питания при короткой задаче

Выбор режима пониженного энергопотребления и блокировка перехода в режим сна — разные механизмы. В справочнике по промежуточному ПО управления питанием (PM) для SF32LB52x и руководстве по низкому энергопотреблению SF32LB55x от SiFli указано, что rt_pm_request(PM_SLEEP_MODE_IDLE) блокирует переход в LIGHT, DEEP и STANDBY до соответствующего вызова rt_pm_release(PM_SLEEP_MODE_IDLE); сам запрос не выбирает более глубокий режим.

При реализации ориентируйтесь на официальное руководство по низкому энергопотреблению для нужного семейства: SF32LB52x, SF32LB55x, SF32LB56x или SF32LB58x. Доступные режимы, условия входа, источники пробуждения и сохранение состояния зависят от семейства микросхем, платы и конфигурации SDK. В руководстве по низкому энергопотреблению SF32LB52x приведён пример настройки пробуждения из Hibernate по выводу, в котором явно сгруппированы варианты 58x/56x/52x/57x. Общий справочник HAL PMU в документации SDK указывает, что для SF32LB57x диапазон индексов, используемых HAL_PMU_EnablePinWakeup(), составляет от 0 до 13. Эти источники подтверждают только данную конфигурацию выводов; они не подтверждают, что поддержка режимов RT-Thread в 52x, пороговые значения политики PM или поведение при сохранении состояния 52x применимы и к 57x. Уточните эти параметры в документации целевого SDK и устройства. В общем случае настроенная политика может выбрать более глубокий допустимый режим только при достаточном интервале простоя и выполнении остальных условий перехода. Неснятый запрос может удерживать систему в более поверхностном режиме, чем предполагалось.

Что расходует энергию в изделии на SF32¶

У каждой подсистемы свой характер энергопотребления:

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

Проектируйте прошивку с учётом сна¶

Наибольшая экономия обычно связана со структурой прошивки, а не с низкоуровневыми приёмами:

• Предпочитайте прерывания и события опросу. Цикл опроса оставляет CPU активным, даже когда нет работы.
• Объединяйте работу в пакеты. Если требования к задержке позволяют, накапливайте отсчёты датчиков, события Bluetooth или блоки аудио и обрабатывайте их вместе, вместо пробуждения для каждого элемента.
• Своевременно снимайте запросы PM, блокирующие сон. Если драйвер или задача удерживает запрос, запрещающий переход в более глубокий режим низкого энергопотребления, соответствующий запрос следует снять, как только блокировка станет не нужна. Иначе система может оставаться в более поверхностном режиме, чем ожидалось.
• Организуйте интерфейс и аудио по событиям, а не по периодическому опросу таймерами, если это допускает используемая программная платформа.
• Проверяйте таймеры. Периодический таймер планирует будущую работу и может пробуждать систему или сокращать интервал простоя, доступный политике PM. Несколько внешне безобидных таймеров могут уменьшить время в более глубоких режимах низкого энергопотребления.

Начните с проверенного примера энергосбережения¶

Перед оценкой автономности выберите пример SDK, который позволит проверить самый неопределённый аспект энергопотребления. В статье «Примеры энергосбережения в SDK» официальные проекты PM, GPIO, процессора, Bluetooth, дисплея, GUI, обновления экрана и включения экрана при поднятии запястья сопоставлены с проверяемыми сценариями. Там также указано, какие предположения о подключении питания, плате, конфигурации, источнике пробуждения, внешней схеме и нагрузке нужно повторно проверить, прежде чем использовать пример как подтверждение для изделия.

Настройка энергопотребления Bluetooth¶

Параметры соединения и рекламирования — основные средства настройки энергопотребления Bluetooth; полная таблица приведена в обзоре Bluetooth:

• Увеличивайте интервал соединения и задержку ведомого устройства для соединений, которые в основном простаивают.
• Снижайте мощность TX до минимального уровня, при котором сохраняется требуемая дальность.
• Передавайте рекламные пакеты реже, когда изделие ожидает повторного подключения, а не первичного обнаружения.
• Если выбранный SDK обрабатывает события Bluetooth-контроллера на отдельном процессоре, CPU приложения может спать между событиями соединения, когда этого не требуют задачи приложения, источники пробуждения или межпроцессорные сообщения. Пробуждение при каждом обратном вызове Bluetooth снижает это преимущество; проверьте распределение ядер и задач на целевом устройстве.

Метод сценарного измерения энергопотребления в трёх вариантах — только Classic Bluetooth, только BLE и совместная работа обоих режимов в двухрежимной конфигурации — описан в статье «Профилирование энергопотребления Bluetooth».

Энергопотребление дисплея и подсветки¶

Дисплей и подсветка часто становятся крупнейшим отдельным потребителем в носимом или портативном изделии:

• Если панель и интерфейс поддерживают это, обновляйте только изменившиеся области вместо полной перерисовки; см. контроллер дисплея: частичное обновление.
• При отсутствии действий пользователя снижайте яркость дисплея или отключайте подсветку, если она предусмотрена; останавливайте анимацию, когда экран затемнён или закрыт.
• Для постоянно включённого экрана сравнивайте панели EPD, JDI/memory-in-pixel, AMOLED и TFT по измеренной энергии в этом режиме и требованиям к пользовательскому интерфейсу. Выбирайте панель и режим работы под энергетический бюджет, а не просто оставляйте обычный активный режим дисплея включённым постоянно.
• Выделяйте постоянно включённый экран в отдельную строку бюджета: он меняет само понятие простоя изделия.

Настройка энергопотребления ИИ и датчиков¶

Инференс на устройстве и опрос датчиков нужно планировать целенаправленно, а не выполнять непрерывно:

• Запускайте инференс только при появлении новых полезных данных, а не по фиксированному таймеру независимо от активности входа.
• Переносите простые постоянно работающие задачи обработки датчиков на энергосберегающий процессор, если устройство и SDK это поддерживают, вместо пробуждения основного CPU для каждого отсчёта.
• Измеряйте энергию на инференс или отсчёт, а не только задержку. Быстрая операция уменьшает расход лишь тогда, когда позволяет раньше вернуться в сон.

Подробнее о компромиссе между точностью, задержкой и потреблением см. обзор ИИ.

Память и тактирование¶

Место выполнения кода влияет на производительность и энергопотребление. В устройствах SF32, где соответствующие кэши реализованы и включены, кэши инструкций и данных могут сократить ожидание обращений к Flash или PSRAM. Более короткое активное время оставляет больше времени для сна. Вопросы кэша и подсистемы памяти рассмотрены в статье STAR-MC1.

Помимо CPU:

• У внешних PSRAM и Flash собственное потребление в активном режиме и режиме Standby. Проверяйте по спецификации затраты на сохранение данных и обращения, особенно если содержимое больших буферов должно пережить сон.
• Выбор источника тактирования, кварца или внутреннего генератора, а также PLL и тактовых доменов, которые остаются активны, влияет на задержку пробуждения и потребление во сне.
• Снижение частоты CPU на менее требовательных этапах может помочь, но нужно проверить, не сведёт ли увеличение активного времени экономию к нулю. Измеряйте реальную энергию, а не только мгновенный ток.

Аппаратная часть и радио¶

Политика прошивки ограничена возможностями аппаратной части:

• КПД PMIC/LDO при реальных токах нагрузки важнее заявленных значений эффективности для нехарактерных режимов нагрузки.
• Радиочастотная разводка и настройка антенны влияют на мощность TX, необходимую для надёжной связи на нужной дальности. Плохая радиочастотная часть вынуждает прошивку повышать мощность и сокращает автономность; см. Bluetooth-процессор: радио и тактирование.
• Точность кварца влияет на временные запасы для радиосвязи, а также на то, насколько консервативно прошивке следует задавать тайм-аут контроля соединения (supervision timeout) и запас времени для пробуждения.
• Предусмотрите на этапе проектирования доступ для производственных испытаний и калибровки. Настройка энергопотребления и радиочастотной части часто продолжается после первой аппаратной ревизии.

Пример: включение экрана при поднятии запястья¶

Включение дисплея при поднятии запястья — типичный сценарий для носимого устройства, но реализация зависит от датчика, платы и SDK. Пример SiFli для SF32LB52x предназначен для платы sf32lb52-lchspi-ulp и использует LSM6DSL (акселерометр/гироскоп): данные ускорения считываются каждые 200 ms для распознавания поднятия и опускания запястья. После 10 секунд бездействия устройство переходит в режим сна, а при обнаружении поднятия запястья просыпается и включает экран. Это пример для конкретной платы; он не подтверждает использование прерываний датчика или такое же поведение PM на других устройствах. Если целевой датчик поддерживает прерывания движения или порогового события, прошивка может настроить их как источник пробуждения, чтобы не опрашивать датчик постоянно с CPU приложения. В противном случае учитывайте выборку датчика и пробуждения CPU в энергетическом бюджете. Проверьте датчик, плату, источники пробуждения и конфигурацию PM для целевого устройства.

Таблица энергетического бюджета¶

До настройки прошивки переведите цели изделия в числа. Обычно достаточно простой таблицы:

Для набора взаимоисключающих рабочих состояний оцените average current = state current x duty cycle, затем сложите вклады состояний. Одновременные нагрузки включайте в итог соответствующего сценария, чтобы не учитывать пересекающиеся состояния дважды. Это позволяет рано увидеть проблемы: цель 20 μA во сне не спасёт изделие, если оно слишком долго использует яркую подсветку или регулярно выполняет инференс независимо от полезной нагрузки.

Профилирование энергопотребления: модель, измерения, уточнение¶

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

flowchart LR
    A["Задать типичные сценарии изделия"] --> B["Задать предположения о токе, напряжении, длительности и частоте"]
    B --> C["Рассчитать энергию на событие и на сутки"]
    C --> D["Сравнить с бюджетом аккумулятора и ранжировать затраты"]
    D --> E["Измерить приоритетные сценарии на целевом оборудовании"]
    E --> F["Уточнить модель по измеренным токам и интервалам"]
    F --> B

Рассматривайте профиль как оценку, а не как измерение. Nordic Online Power Profiler for Bluetooth LE следует тому же принципу: использует модели, полученные из измерений, но выдаёт ожидаемые значения, а не измерение конкретного изделия. Ток зависит от кремния, конструкции платы, напряжения аккумулятора, температуры, радиоусловий, временных параметров прошивки и сценария использования.

Для каждого сценария запишите предположения, существенно влияющие на энергию:

• Какие подсистемы включены и в какой режим питания MCU фактически переходит?
• Каков ток на входе питания от аккумулятора или на каждой стабилизированной линии?
• Сколько длится работа и сколько раз она происходит за типичные сутки?
• Какие пики тока ожидаемы, а какие указывают на лишнюю работу или несостоявшийся переход в сон?

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

Проверка ответственности за PM и источников пробуждения¶

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

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

Измерение на практике¶

Не гадайте — измеряйте. Базовый стенд для проверки энергопотребления включает:

• Токовый пробник или анализатор мощности между аккумулятором/источником питания и платой.
• Сценарии, соответствующие реальному использованию: ожидание при подключении, работа интерфейса, воспроизведение аудио, короткие запуски инференса ИИ и максимальная совместная нагрузка.
• Запись или маркеры состояний прошивки (активность, ожидание, сон) вместе с осциллограммой потребления, чтобы связать пики тока с конкретными участками кода.

В документации SiFli SDK приведены примеры измерения потребления для отдельных устройств и плат, в том числе сценарии с AMOLED- и JDI-дисплеями, GPIO, BLE/Bluetooth Classic и нагрузкой CPU типа CoreMark. Проверьте документацию целевого SDK и платы, чтобы убедиться в наличии примера и порядке его настройки. Подходящие примеры можно использовать как шаблон измерений и проверку правдоподобия, но они не гарантируют потребление готового изделия.

Матрица проверки энергопотребления¶

Используйте повторяемые сценарии, чтобы сравнивать улучшения между ревизиями прошивки. Как минимум измерьте:

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

Поиск причин высокого энергопотребления¶

Типичные ошибки¶

• Отсрочка оптимизации потребления до завершения проекта вместо учёта её как ограничения с первого дня.
• Опрос датчиков, состояния Bluetooth или таймеров вместо прерываний и событий.
• Удержание запроса PM после окончания работы, ради которой он был нужен.
• Полная перерисовка дисплея при небольшом изменении интерфейса.
• Игнорирование качества радиочастотной разводки и компенсация повышенной мощностью TX в прошивке.
• Измерение только мгновенного тока вместо энергии реального сценария использования.
• Проверка только на стенде, без окончательного корпуса, реальной антенны и аккумулятора.

Контрольный список первоначального запуска¶

• Задайте целевую автономность, долю времени в рабочих состояниях и необходимые источники пробуждения.
• Определите подсистемы, которым нужно работать постоянно, и подсистемы, работу которых можно полностью организовать по событиям.
• Убедитесь, что каждый драйвер и каждая задача своевременно снимают свой запрос PM после завершения работы.
• Настройте параметры рекламирования и соединения Bluetooth под реальное использование изделия.
• Проверьте частичное обновление дисплея, если оно поддерживается, и соответствие политики подсветки поведению изделия.
• Проверьте все периодические таймеры, удалите или объедините ненужные.
• Подготовьте измерение тока и отдельно проверьте активность, ожидание и сон.
• Проверьте максимальную совместную нагрузку (Bluetooth + дисплей + аудио + ИИ, если применимо) на соответствие энергетическому бюджету.
• Повторяйте проверку после каждого существенного изменения прошивки, а не только в конце проекта.

Основные выводы¶

• Энергопотребление — свойство всей системы: Bluetooth, дисплей, аудио, ИИ и память определяют глубину и частоту сна.
• Настроенная политика PM выбирает допустимое состояние низкого энергопотребления; неснятый запрос, блокирующий более глубокие режимы, может оставить систему в более поверхностном состоянии, чем планировалось.
• В проектах с низким энергопотреблением событийный подход и прерывания почти всегда эффективнее опроса.
• Параметры соединения Bluetooth и политика обновления дисплея обычно дают две крупнейшие возможности экономии в подключённом носимом изделии.
• Измеряйте энергопотребление при типичных совместных нагрузках на реальном устройстве в окончательном корпусе. Измерения на стенде и отдельных подсистемах могут занижать энергопотребление готового изделия.

Как оценить оставшийся заряд аккумулятора по напряжению, описано в разделе Оценка уровня заряда аккумулятора.

Последнее обновление: 2026-10-21