Сравнительные измерения тока сна ESP32-S3, ESP32-C3 и ESP32-C6
Три платы XIAO на ESP32-S3, ESP32-C3 и ESP32-C6 измерены анализатором мощности в режимах Modem-sleep, Light-sleep и Deep-sleep; результаты сопоставлены с даташитами Espressif и Seeed Studio и показывают расхождения в разы.
У каждого устройства с батарейным питанием есть нижняя граница потребления — ток, который оно потребляет, когда вообще ничего не делает. Радиомодуль ещё не активирован, датчики не опрашиваются, прикладная логика не работает, и вся плата находится лишь в самом глубоком режиме сна. Эта нижняя граница задаёт нижний предел срока службы батареи и одновременно является одним из наиболее объективно указываемых параметров в даташите: ток сна прямо приводится в таблице электрических характеристик с точностью до микроампер (мкА).
Эта серия статей отталкивается от такой нижней границы: на испытательном стенде измерены три популярные платы семейства ESP32 — ESP32-S3 с двухъядерной архитектурой Xtensa, ESP32-C3 на RISC-V и ESP32-C6 с поддержкой протокола 802.15.4. У этих плат разные ядра, разная конфигурация памяти и разная радиочастотная архитектура. Фокус измерений — реальный ток каждой платы в глубоком сне, его сравнение между платами и сопоставление с номинальными значениями из соответствующих даташитов.
Потому что цифры в даташите — лишь отправная точка, а не окончательный ответ. Они получены в определённых условиях испытаний (как правило, на голом кристалле) и крайне редко полностью соответствуют модулю на плате у вас на столе. К тому же, в зависимости от того, какие модули сохраняют питание, «глубокий сон» может соответствовать нескольким совершенно разным состояниям. В следующей статье мы добавим поверх этого беспроводные протоколы — BLE, Wi-Fi или Thread; но прежде необходимо выяснить, соответствует ли базовое статическое потребление номиналу из даташита.
Даташиты SoC Espressif приводят значения, измеренные на голом кристалле при 3,3 В, 25 °C и без каких-либо внешних компонентов. Эти данные задают теоретическую нижнюю границу потребления.
Примечание: опубликованные в даташитах Espressif значения для режима Modem-sleep соответствуют состоянию простоя CPU. При этом Espressif перечисляет несколько подсостояний (CPU работает или простаивает, тактирование периферии включено или выключено и т. д.). В данной проверке использовалось состояние WAITI (простой CPU) при тактовой частоте 160 МГц.
Документация уровня платы Seeed Studio (矽递科技) учитывает вклад всех компонентов на плате: LDO-стабилизатора, управления батареей, моста USB–UART и внешней флеш-памяти.
Никакая таблица не предскажет точно, сколько устройство будет потреблять в реальных условиях: фактическое потребление зависит от того, как взаимодействуют аппаратура, прошивка и приложение. Даташит очень полезен при оценке проекта, но если вас волнует реальное время автономной работы устройства, важнее всего реальные измерения.
Мы протестировали три платы с помощью анализатора мощности Otii Ace Pro (частота выборки 50 тыс. отсчётов/с, разрешение 0,4 нА), подключённого к выводу VBAT каждой платы.
Напряжение питания через контактные площадки батареи было установлено 3,8 В. Значения в даташитах Espressif получены при 3,3 В, приложенных непосредственно к микросхеме, но на платах XIAO между входом батареи и микросхемой стоит встроенный LDO, которому требуется входное напряжение выше 3,3 В, чтобы стабилизатор работал в своём допустимом номинальном диапазоне.
Тестовая прошивка собрана в PlatformIO на ESP-IDF 5.5.3. Каждая плата выполняла одну и ту же последовательность конечного автомата: сначала 10 секунд загрузки с мигающим светодиодом, затем по очереди 15 секунд Modem-sleep, 15 секунд Light-sleep и 15 секунд Deep-sleep. Кроме единственного вывода GPIO для управления светодиодом, никакая другая периферия не инициализировалась.
В первом раунде измерений S3 показал ток в Light-sleep 2,88 мА (жёлтая кривая на графике). Значение соответствует спецификации платы Seeed, но намного выше 240 мкА, указанных в даташите SoC. Это заметное расхождение обусловлено внешней SPI-флеш-памятью. По умолчанию ESP-IDF во время Light-sleep оставляет внешнюю флеш-память под питанием. Ядро SoC переходит в режим малого потребления, но выводы шины SPI не изолированы, что приводит к перекрёстным утечкам между выводами либо удерживает микросхему флеш-памяти в активном ожидании, добавляя от 1,5 до 2,5 мА.
Установкой CONFIG_ESP_SLEEP_POWER_DOWN_FLASH=y настраивается управляемое прошивкой аппаратное отключение питания: стабилизатор принудительно снимает питание с микросхемы флеш-памяти (VDD_SPI) при переходе в сон. Одна эта строка конфигурации снизила ток ESP32-S3 в Light-sleep с 2,88 мА до 692 мкА — на 76%.
Но в отличие от S3, у ESP32-C3 и ESP32-C6 на архитектуре RISC-V включение аппаратного отключения питания почти ничего не изменило: ток C3 слегка снизился с 204 до 193 мкА, ток C6 — с 233 до 220 мкА.
Экономия здесь минимальна, потому что на этих микросхемах программно управляемая изоляция выводов, включённая по умолчанию, уже устраняет подавляющую часть тока утечки; сэкономлено лишь 11–13 мкА тока ожидания. Ситуация с ESP32-S3 совершенно иная: на S3 та же настройка устраняет основной путь аппаратной утечки через выводы, что и даёт резкое падение потребления.
Эти результаты показывают, что оптимизация энергопотребления работает по-разному на разных архитектурах. Мера, дающая заметный эффект на одной SoC, на другой может принести лишь крохотное улучшение. Тем не менее применить эту оптимизацию на всех платах — хорошая практика.
Итоговые проверенные результаты измерений при одинаковой тестовой последовательности, одинаковых условиях и питании 3,8 В через вывод батареи для каждой платы сведены в таблицу ниже.
Примечание: Modem-sleep измерялся на частоте 160 МГц в состоянии простоя CPU (WAITI). Радиостек не инициализирован. Каждая фаза длилась 15 секунд.
В спецификациях плат Seeed ток Light-sleep указан как 2 мА (S3), 4 мА (C3) и 3,1 мА (C6). Проверенные измеренные значения — 692 мкА, 193 мкА и 220 мкА соответственно, что в 3–21 раз ниже номинала.
Расхождение объясняется радиомодулем. Данные Seeed основаны на предположении, что устройство во время сна сохраняет подключение по Wi-Fi, поэтому радиочастотный тракт должен периодически пробуждаться для приёма маяков DTIM точки доступа. В нашем тесте радиостек не инициализировался: измеренный ток включает только ток удержания SRAM и накладные расходы платы, что соответствует практике батарейных устройств, выключающих радио перед сном. Если для расчёта ёмкости батареи в проекте с «выключенным радио» напрямую взять спецификацию Light-sleep от Seeed, вклад тока в фазе Light-sleep будет завышен в 4–21 раз — в зависимости, конечно, от модели платы.
Среди трёх плат показания S3 в 3,5 раза выше, чем у C3 и C6. Это определяется архитектурой: ESP32-S3 имеет 512 КБ SRAM, разделённых на несколько доменов удержания, каждый из которых потребляет ток во время Light-sleep. У C3 и C6 объём SRAM меньше и доменов удержания меньше. Если проект подразумевает длительное пребывание в Light-sleep, это архитектурное различие напрямую скажется на времени автономной работы.
Даташит SoC C3 указывает ток Deep-sleep 5 мкА — самый низкий из трёх микросхем. Однако измеренное на плате значение достигло 41,6 мкА — выше, чем у S3 (13,4 мкА) и C6 (16,9 мкА).
Первое показание было и вовсе 461 мкА. Причина — вызов gpio_deep_sleep_hold_en(), распространённой в IDF функции для удержания состояния GPIO в глубоком сне. На XIAO ESP32-C3 светодиод подключён к GPIO 10, который относится к цифровому домену, а не к домену RTC. Вызов функции удержания для вывода не из RTC-домена не вызывает ни предупреждения компилятора, ни ошибки времени выполнения, но незаметно создаёт ток утечки через цепь светодиода. После удаления этого вызова показание упало с 461 до 41,6 мкА.
На S3 та же функция работает корректно, потому что GPIO21 поддерживает RTC. Такое же исправление мы применили на C6 (его светодиод подключён к GPIO15, также без поддержки RTC). Набор выводов с поддержкой RTC у разных моделей различается: S3 — GPIO 0–21, C3 — GPIO 0–5, C6 — GPIO 0–7. Перед использованием gpio_deep_sleep_hold_en() обязательно проверяйте, к какому домену питания относится вывод.
Допустим, узел с датчиком пробуждается каждые 60 секунд, работает 500 миллисекунд и снова уходит в Light-sleep. В этом примере используется Light-sleep, а не Deep-sleep, поскольку многие реальные приложения (например, периферийные устройства BLE) между событиями должны оставаться в Light-sleep для более быстрого пробуждения. Оценку срока службы батареи мы выполнили в Otii Battery Calculator (функция калькулятора времени работы батареи Otii) с батареей 800 мА·ч и консервативным активным током 30 мА.
Разрыв здесь весьма значителен. Если оценивать время работы батареи для проекта с выключенным радио прямо по номиналам из даташита Seeed, реальное время автономной работы будет занижено в 3–21 раз (в зависимости от модели платы).
В приведённых расчётах использованы фиксированный средний ток и фиксированная ёмкость батареи — этого хватает для быстрого сравнения и проверки на здравый смысл, но для оценки серийного изделия совершенно недостаточно. В реальных условиях разряд батареи нелинеен, напряжение отсечки уменьшает доступную ёмкость, а изменения температуры влияют и на батарею, и на само устройство. Чтобы учесть эти факторы, Otii Battery Life Estimator (функция точной оценки времени работы батареи Otii) использует пользовательскую модель разряда батареи, построенную под реальное применение, и сочетает её с моделью потребления системы при выполнении разных действий, давая прогноз, более близкий к действительности. Подробнее об этом — в следующих статьях.
Итак, мы рассмотрели реальное поведение трёх плат ESP32 в самом глубоком сне: сравнение моделей между собой и расхождения между номиналами даташитов и измеренными значениями. Эти расхождения и есть суть проблемы. Цифры даташита отражают поведение микросхемы лишь в идеальных условиях: референсный дизайн, контролируемый стенд и конкретная конфигурация сна. Реальный продукт работает в совершенно другой среде — со своими стабилизаторами, настройками прошивки и состояниями выводов, которых даташит не измерял.
И это, возможно, лишь верхушка айсберга. Ток глубокого сна — самое предсказуемое состояние платы. Но даже здесь даташит может служить лишь отправной точкой. В следующих статьях наша команда добавит поверх этой базы BLE, Wi-Fi и Thread — и тогда рабочий цикл, тайминги протоколов и состояние сети могут ещё сильнее увести реальное потребление от любого единственного номинала.
Именно поэтому базовые данные так важны — и получать их нужно на вашем реальном оборудовании. Обязательно измеряйте потребление собственной платы с собственной прошивкой в реальных условиях работы продукта. Эти измерения составят реальный профиль потребления; объединив его с реальной моделью разряда батареи, можно точнее предсказать, сколько устройство проработает от конкретной батареи. Только так можно правильно выбрать ёмкость батареи до утверждения размеров корпуса, поймать регрессии прошивки до рассылки OTA-обновлений в поле и передать заказчику технические характеристики, выдерживающие проверку.
Пропустив этот шаг, разработка продукта сводится к догадкам. А в реальной разработке ошибочная догадка означает выезд техников на место, массовые возвраты и невосполнимую потерю доверия клиентов.