Встраиваемые системы

Низкое энергопотребление

В 2019 году компания Tile перешла с CR1632 батареи на CR2032 в своих BLE-трекерах и заявила срок жизни 'до 3 лет'. Цена ошибки в low-power дизайне для них - возврат миллионов устройств клиентам. Инженеры борются за каждый микроампер: алгоритм advertising переписан так, чтобы radio просыпался на 0.4 мс вместо 1.2 мс, MCU выбран с лучшим deep sleep current (nRF52832 - 0.3 мкА в System OFF), printf удалён из production-кода (UART жрал 200 мкА постоянно). Watchdog timeout вырос с 30s до 4s после инцидента, когда firmware bug заставил 10000 устройств зависнуть до user-replacement батареи.

  • **Apple AirTag**: CR2032 батарея, время жизни ~1 год - использует nRF52832 в System OFF (0.3 мкА) + Ultra-wideband chip пробуждается только при ranging-запросе
  • **Mars Rover Perseverance**: солнечные панели + Li-ion buffer + IWDG на каждом из 7 sub-processor'ов - устройство выживает в -120°C ночах через aggressive sleep + heater cycling
  • **Implantable medical devices** (кардиостимуляторы Medtronic): батарея 0.5 Ач должна работать 10 лет - средний ток <10 мкА, watchdog обязателен по FDA, прошивка проходит formal verification

Sleep modes: иерархия экономии

Современные MCU (STM32, nRF52, ESP32) имеют 4-6 уровней сна, каждый отключает дополнительные блоки чипа. **Active** - всё работает, потребление 5-20 мА. **Sleep** - CPU остановлен, периферия активна, ~1 мА. **Deep sleep** - выключены большинство тактирований, остаётся RTC и SRAM, 5-20 мкА. **Standby / Power-off** - выключено всё кроме wakeup-пинов, 0.1-1 мкА. Разница между Active и Standby - **в 100,000 раз**: устройство, работающее 1 день в Active, проработает 270 лет в Standby (физика батарей в реальности ограничит этот срок ~10 годами self-discharge).

Стоимость пробуждения: переход из глубокого сна в active занимает 10-1000 мкс (зависит от того что нужно re-init: PLL, flash, peripherals). Если устройство просыпается 100 раз в секунду для обработки прерывания и сразу засыпает, накладные расходы wakeup могут съесть весь выигрыш. **Правило**: продолжительность активной фазы должна быть много больше времени transition. Для частых wakeups используют менее глубокий sleep mode.

IoT-сенсор температуры на CR2032 (~230 мАч) должен работать 5 лет. Измерение - раз в 15 минут (50 мс активной работы при 10 мА). Какой средний ток допустим, и какой sleep mode подходит?

Power management: peripherals и тактирование

Sleep modes - грубый инструмент, тонкая оптимизация - это **clock gating** и **power gating** отдельных блоков. Современные MCU имеют десятки тактируемых периферийных блоков (USART, I2C, SPI, ADC, TIM, USB) - каждый можно включить/выключить независимо. Не используете USART2? Выключите его тактирование - сэкономите 100 мкА в active. Не нужен USB во время измерения? Power gating USB-блока экономит ещё мА. Принцип - **выключено всё, кроме того что нужно прямо сейчас**.

**DVFS (Dynamic Voltage and Frequency Scaling)** - снижать и частоту, и напряжение питания одновременно. Динамическая мощность ~ C * V² * f, поэтому снижение V с 3.3V до 1.8V даёт экономию **в 3.3 раза** при той же частоте, плюс снижение f даёт ещё кратный выигрыш. Для CPU это значит работать быстро и идти в sleep ('race to idle'), но для I/O-связанных задач - наоборот, медленно но непрерывно. Современные ARM Cortex-M33 и RISC-V чипы поддерживают это аппаратно.

Устройство выполняет крипто-вычисление AES (10 мс на 80 MHz). Какой подход даст меньшее энергопотребление при той же task?

Energy harvesting: жизнь без батареи

**Energy harvesting** - сбор энергии из окружающей среды: солнечный свет (фотовольтаика), вибрации (пьезо), тепло (термопары/Peltier), RF-волны (от Wi-Fi/мобильных вышек). Бюджеты крошечные: фотоэлемент 1 см² на солнце даёт ~10 мВт, в офисе - 10 мкВт, пьезо-харвестер с вибраций машины - 100 мкВт. Это значит дизайн системы кардинально меняется: вместо 'батарея на 5 лет' получаем 'устройство работает только когда есть энергия + super-cap буферизует пики'.

**Intermittent computing** - программная модель для energy-harvesting устройств: задача разбивается на checkpoint'ы, между ними состояние сохраняется в non-volatile memory. Устройство может потерять питание в любой момент и продолжить с последнего checkpoint при возобновлении. Используется в академических проектах (Wisp - программируемые RFID-теги, питаются от Wi-Fi) и коммерческих сенсорах ASSA ABLOY EcoFlex для дверных замков (питание от вращения ручки).

Энергохарвестер на пьезо-элементе генерирует 100 мкВт при вибрации мотора. Для трансмиссии BLE-пакета нужно 30 мДж за 200 мс (мощность 150 мВт). Как это совместить?

Watchdog: страховка от зависаний

Устройство ушло в deep sleep и не проснулось из-за зависшего ISR? Утечка тока на брак-чипе разрядила supercap? **Watchdog** - аппаратный таймер, который автоматически перезагружает MCU, если ПО не сбрасывает его в течение T секунд. Программа обязана периодически 'погладить watchdog' (kick / pet / refresh), иначе - hardware reset. Это последняя линия обороны embedded-устройства: тысяч строк кода могут содержать deadlock, но watchdog гарантирует, что устройство не зависнет навсегда.

В аэрокосмических и медицинских устройствах watchdog часто **многоуровневый**: внутренний IWDG (защита от software hang), внешний watchdog-чип (TPS3823, защита от sw + hw glitches), и опционально - external supervisor с brownout detection (выключает устройство, если напряжение упало ниже porog). Стандарт DO-254 (RTCA) требует watchdog в аппаратуре уровня DAL-A. В Mars Rover Curiosity watchdog reset спас миссию в 2013 году - устройство 'выкарабкалось' из bad state без вмешательства Земли.

Watchdog - просто страховка 'на всякий случай', можно ставить любой timeout с запасом (например, 1 минута).

Watchdog timeout должен быть подобран близко к максимальному ожидаемому времени между kicks (с разумным запасом). Слишком большой timeout означает что система может 'висеть' минуту до reset - в medical/aerospace это недопустимо.

Watchdog - не просто 'reset когда зависло', это контракт о времени отклика системы. Если timeout 60s, а программа должна реагировать на пользователя за 1s, то WD не защитит от bad UX (60s zависа). С другой стороны, слишком короткий timeout (например, 100ms) усложнит правильно расставлять kicks в коде с длительными legitimate-операциями. Правило: T_wd = 2-3x от ожидаемого максимального time-to-kick.

В коде есть `HAL_Delay(15000)` (блокирующая задержка 15 секунд) внутри основного цикла. Watchdog настроен на 8 секунд. Что произойдёт?

Ключевые идеи

  • **Sleep modes** - иерархия 4-6 уровней, разница в потреблении между Active и Standby - до 100000x; выбор зависит от частоты wakeup и допустимого latency
  • **Power management** - clock gating, power gating, DVFS, 'race to idle': выключать всё неиспользуемое, делать работу быстро и в sleep
  • **Energy harvesting** - solar, piezo, RF, thermal; крошечные бюджеты (10-100 мкВт) требуют supercap-буфера и intermittent computing с checkpoint в NVM
  • **Watchdog** - hardware reset при software hang, многоуровневый для critical-систем; timeout подбирается под реальное max-time-to-kick (2-3x запас)
  • Главный принцип low-power дизайна: 'процессор должен спать столько, сколько возможно, и работать столько, сколько необходимо'

Связанные темы

Low power - сквозная тема embedded, связана со многими модулями:

  • Прерывания и DMA — DMA позволяет передавать данные без участия CPU - CPU спит, DMA работает, перерывание будит только когда transfer done
  • RTOS — FreeRTOS/Zephyr имеют 'tickless idle' - выключают системный tick в idle, MCU спит между задачами
  • LoRa и LPWAN протоколы — LoRa дизайнен для long-battery-life IoT - duty cycle <1%, deep sleep между TX

Вопросы для размышления

  • Если устройство просыпается 10 раз в секунду на 1 мс каждый раз - какой sleep mode имеет смысл? Что если 1 раз в час на 100 мс?
  • Энергобюджет CR2032 batterи (~230 мАч) на 5 лет = 5 мкА средний ток. Какие компоненты вашей системы могут 'съесть' этот бюджет незаметно?
  • Watchdog timeout 8 секунд - это много или мало? От чего зависит выбор для конкретного устройства?

Связанные уроки

  • emb-12 — Bootloader управляет sleep/wake последовательностью
  • emb-14 — Safety-critical требуют гарантий watchdog и power fail
  • emb-10 — BLE и LoRa требуют duty-cycle power budgeting
  • prob-12-lln — Energy harvesting - интеграция случайного процесса по времени
  • arch-08-memory-hierarchy
Низкое энергопотребление

0

1

Войти