Встраиваемые системы
Низкое энергопотребление
В 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