Оптимизация энергопотребления в lora-at
При начале работы по оптимизации энергопотребления LoRa, я даже не представлял, насколько глубокой может быть эта тема. В предыдущих частях я рассказывал о:
В этот раз возникла идея оптимизации цикла глубокого сна. Если кратко, то работа в режиме глубокого сна выглядит следующим образом:
- Если приложение не активно в течение определенного времени, то
- Перейти в режим глубокого сна на определенное время
- Через определенный интервал времени ESP32 просыпается
- Выполняет полезную работу и возвращается к шагу 2
Шаги с второго по четвертый образуют цикл глубокого сна. Обычно время выполнения полезной работы значительно меньше времени, в течение которого устройство находится в режиме сна. Однако энергопотребление в этот период существенно выше, и именно этот интервал требовал оптимизации.
Загрузка ESP32
Оказалось, что ESP32 не сразу передает управление пользовательской программе. Просмотр логов показал:
I (29) boot: ESP-IDF v5.1-dev-2633-g8464186e67-dirty 2nd stage bootloader
I (29) boot: compile time Dec 5 2023 20:47:42
...
I (552) main_task: Calling app_main()
До запуска программы проходит 552 миллисекунды! Даже если программа оптимизирована и выполняется за 1-2 миллисекунды, это ничтожно мало по сравнению с временем загрузки микроконтроллера.
Активный режим работы lora-at до всех оптимизаций выглядел так:
Оптимизации
Первую оптимизацию я неосознанно сделал еще при переписывании на С. Bootloader проверяет программу на целостность и загружает ее в память. Чем меньше программа, тем быстрее загрузка.
Далее я решил обратиться к интернету за дополнительными идеями. В этот раз повезло: в официальной документации есть глава, посвященная оптимизации программ. Вот список того, что мне пригодилось:
- Отключение проверки целостности программы при выходе из режима глубокого сна. Можно отключить полностью, но я не стал, так как lora-at может работать по проводу, где потребление энергии не так критично.
- Использование Quad I/O на скорости 80 МГц при загрузке прошивки в память (необходимо проверить поддержку конкретной платы в datasheet)
- Включение оптимизаций на уровне GCC компилятора:
-O2
- Логирование только ошибок (ERROR) при загрузке bootloader
- Логирование только предупреждений (WARN) во время работы прошивки, с возможностью ручной установки уровня INFO в случае подключения к батарее и солнечным панелям
После всех оптимизаций режим работы выглядит так:
Время работы сократилось с 608мс до 67мс, а потребляемый заряд с 27.20мКл до 3.06мКл - более чем в 8 раз!
Вполне достойный результат. Но как изменится потребление если увеличить частоту чипа с 80Мгц до 240Мгц? БОльшая частота - это бОльшее потребление энергии, но при этом и бОльшая скорость работы.
Ого! Оказывается работа на частоте 240 МГц оказалась более выгодной, чем на 80 МГц: 2.51 мКл против 3.06 мКл.
Продолжение следует
Эти оптимизации применены для цикла глубокого сна, где lora-at переходит в спящий режим каждые 5 секунд. В реальности программа должна инициализировать bluetooth, получать время следующего наблюдения и входить в спящий режим. У меня есть два алгоритма:
- Переход в спящий режим до следующего наблюдения
- Переход в спящий режим на фиксированное время
Во втором случае можно отправлять на RaspberryPI информацию о состоянии батареи и/или солнечной панели. Это поможет лучше понимать условия работы, но при этом будет тратиться дополнительная энергия. Надо провести измерения.