Кста, работает только на системах с одним NVMe или NVMe+SATA SSD

На двух NVMe работает через раз, поскольку MAJ:MIN меняются.
Я удалил этот файл вовсе, и после перезагрузки пункт гибернации вернулся.

+, нужно определить systemd-override, иначе система попросту не уйдет в гибернацию.
Тогда нужно сделать следующее:
1) Создать дерево каталогов, если не существует:

sudo mkdir -p /etc/systemd/system/systemd-hibernate-resume@.service.d

2) Создать конфиг:

sudo nano /etc/systemd/system/systemd-hibernate-resume@.service.d/override.conf

и заполнить:

[Service]
ExecStartPre=/usr/bin/bash -c 'for dev in /dev/disk/by-uuid/*; do if blkid "$dev" | grep -q "TYPE=\"swap\""; then echo "Автоопределение swap: $dev"; echo "${dev##*/}" > /run/resume_uuid; echo ${dev##*/} > /sys/power/resume; break; fi; done'

3) Перезагрузить юниты:

sudo systemctl daemon-reexec
sudo systemctl daemon-reload

Перезагрузиться на всякий.
После этого гибернация должна надежно работать. Проверю - отпишусь, если что-то не так.

Ага! Вы думали, я пропал?

С момента прошлой публикации произошло много интересных событий, но самое важное из них в контексте этого канала – я, наконец, принял решение плотно заняться электроникой, схемотехникой и всем, что связано с различными электронными устройствами.

Как обычно происходит знакомство с миром встраиваемой электроники в современных условиях? Покупается плата или набор Arduino, и новоиспеченный системщик начинает копаться во множестве библиотек, шилдов, фреймворков и питоновых скриптов.

Конечно же, я выбрал другой вариант. Когда-то давно я начинал свой путь в большое программирование с ассемблера. Тогда это были приложения под платформу x86 для Windows. С тех пор прошло 20 лет, и вот я снова решил вернуться к своим корням.

Поэтому моё погружение в чудесный мир электронных устройств началось с изучения ассемблера под современную архитектуру RISC-V. Первым делом нужно установить и настроить всё необходимое для сборки, отладки и заливки прошивок на устройство. Но внезапно выяснилось, что в мире ардуинщиков очень непросто найти информацию о том, как настраивать сборочные тулчейны, кросс-компиляцию и тому подобные вещи. Так что пришлось в этом всём разобраться своими силами. Заметка получилась довольно длинной и в формат поста в телеге не помещается. К счастью, у меня есть сайт, который как раз для этого и создавался!

Собственно, вот ссылка на заметку: https://andreichevozerov.ru/blog/risc-v-asm-toolchain/

Скорее всего, режим доставки я и не получу, пока не реализую хотя бы минимальную логику управления по I2C.
Кнопкой RST можно только передернуть BATTFET (это внутренний транзистор, который соединяет аккумулятор напрямую с выходом).
А чтобы войти в режим доставки, надо отправить команду по I2C (аналог полного отключения устройства).
А удержанием реализуется холодный перезапуск (по напряжению на выходе и было видно)

Итак, что за зверь - плата контроллера питания MP2722

MP2722 заявлен как программно-управляемый контроллер заряда с прямым подключением нагрузки к аккумулятору (NVDC - Narrow Voltage Direct Current converter), а также режимом доставки (когда потребитель отключен от аккумулятора, от его заряд ооочень мало расходуется), а также с поддержкой определения типа зарядного устройства и OTG (то есть, от контроллера можно заряжать другие устройства).
Идея этой платы такая:
- контроллер MP2722 с программным управлением по I2C
- два домена питания (постоянный 3.3В и подключаемый 4.2/5/9/12В, по выбору)
- кнопка проброшена на MP2722 и на целевой контроллер
- выдача тока заряда/разряда на аналоговый выход с MP2722
- детекция типа зарядного устройства как по Type-C, так и по линиям данных USB D+/D-
- при этом, USB-порт может быть проброшен на целевой контроллер. Реализовано за счет цепи, которая временно переключает USB-порт на MP2722 для детекции типа зарядки, и действует независимо от целевого контроллера
- логика управления зарядкой, разрядкой, отслеживания входного напряжения, микроциклы во время постоянного питания от USB реализованы на MP2722, но значения и параметры можно смотреть и менять с целевого контроллера
- формат макетной платы, которую удобно подключать в беспаечную макетку

Такой модуль призван решить задачу батарейного питания устройств с большой батареей, которые нужно через один порт и заряжать аккумулятор за приемлимое время, и подключать к компьютеру для обмена данными. Например:
- фотоловушки
- логгеры
- рации
- камеры
- и другое
Ну или для сценариев, где аккумулятор - это резервный источник питания.

Если заинтересованы - дайте знать😉

А между прочим
Нас уже 100🎉

Строю библиотеку управления состоянием питания устройства с использованием MP2722

Во многих проектах, вернее, в примерах работы с платами и даже в обучалках по контроллерам, встречался с описаниями интерфейсов/регистров, чтобы перевести устройство в режим сниженного энергопотребления. Даже встречался с платами типа TTGO T-Call, в которых есть контроллеры питания.
Однако пока не видел ни библиотек, ни проектов, где организована схема управления питанием устройств, и хотел бы данную проблему решить.
Также хотелось бы с помощью библиотеки power_management покрыть и случаи, когда команда контроллеру "отключить питание" либо недоступна, и происходит только отключение потребителя от батареи, либо доступен только перезапуск.
Сейчас есть минимальная рабочая версия библиотеки в составе примера проекта с контроллером MP2722 и с библиотекой. Пока привожу логику в порядок, думаю, как это наглядно продемонстрировать, возможно, еще напишу статью на Хабр.

Репозиторий с проектом: https://gitflic.ru/project/dmitrij99925/primer-proekta-dlya-upravleniya-kontrollerom-pitaniya-mp2722

Хотел бы покрыть случай, такие как:
- стандартный: зажали кнопку включения, контроллер питания подает питание на систему -> запускать систему
- устройство в выключенном состоянии поставили на зарядку -> показать на экране процесс зарядки
- контроллер питания почему-то решил подать питание, когда система была выключена -> сразу выключить
- устройство на зарядке, но пользователь решил зажать кнопку, ожидая включения устройства -> включить устройство
- устройство пытаются включить, но аккумулятор критически разряжен -> показать соответствующий экран и выключить
- устройство включили, взаимодействуют с ним и забили на него -> выключить по истечении времени бездействия
- устройство в спящем режиме, но периодически просыпается
- устройство постоянно питается от сети, аккумулятор как резервный источник питания, но на данный момент зарядное устройство отключено и скоро устройство отключится
и другие сценарии.

Проблема в том, что ESP32x-контроллеры в Deep-Sleep режиме обесточивают SRAM, из-за чего содержимое ОЗУ и некоторых регистров пропадает (но можно сохранять состояния во встроенной RTC Memory). При просыпании из Deep-Sleep нет разницы, сбросили устройство или оно проснулось по таймеру из Deep-Sleep. несмотря на возможность получить причину запуска, многое из периферии необходимо переинициировать, но при этом также нужно поднимать состояние устройства, например, из RTC Memory. Если использовать Light-Sleep, то состояние SRAM и регистров будет сохраняться, но если нужно сильно снизить потребление, то используется именно Deep-Sleep.

Дорогие подписчики!

От всей души поздравляю вас с наступающим 2026 годом!

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

* схемы собирались легко и работали стабильно;
* компиляции проходили без ошибок, а отладка занимала минимум времени;
* алгоритмы были оптимальны, а ресурсы — достаточны;
* идеи приходили вовремя, а вдохновение не иссякало.


Пусть в 2026 году вас ждут:
* новые знания и навыки в сфере схемотехники и программирования;
* интересные проекты и достойные вызовы;
* надёжные компоненты и стабильные библиотеки;
* коллеги, с которыми приятно работать, и клиенты, ценящие ваш труд.

Желаю вам крепкого здоровья, душевного равновесия и радости от каждого дня. Пусть дома будет тепло и уютно, а в сердце — уверенность в завтрашнем дне.

С Новым 2026 годом!🎄 Пусть он принесёт вам успех, гармонию и множество маленьких технических чудес.

Сделал замеры потребления тока установки на базе контроллера питания MP2722 и платы Guition JC4827W543C (дисплейный модуль)

Использовал аккумулятор с заявленной емкостью 1800 мАч.

Дисплейный модуль пришлось доработать:
- отключил контроллер питания от пауэрбанка IP5306 (у него кривая схема управления питания и с контроллера никак нельзя с ним взаимодействовать, версия не-I2C)
- вывел отвод для подачи питания с моего контроллера питания
- пробросил кнопку на IO16

Активное потребление вышло более 100 мА, притом, без подключения WiFi
Потребление в спящем режиме (без дополнительного вмешательства) - ~60 мА: так получилось из-за неактивированного спящего режима на дисплее NV3041 и тач-контроллере GT911, а также из-за цифрового усилителя мощности NS4168

После отключения NS4168 потребление в спящем режиме упало до ~30 мА.
Когда отключил еще и дисплей с тачем, то потребление упало до 9 мА.

Потребление в выключенном режиме составило ~60 мкА.

Вывод:
- вся установка без дополнительной оптимизации по питанию в выключенном состоянии пролежит ~3 года и сможет в течение этого времени включиться без подзарядки
- если нужна доп-оптимизация по питанию в спящем режиме, то надо делать свою плату. И найти, куда идут 9 мА потребления.

Офис делал мне мозги

Пытался написать инструкцию, а Microsoft Office зависал через какое-то время после запуска, и даже документ не сохранялся, даже после переустановки.
При этом, переустановка или обновление офиса не помогало.
До этого был KMS-активатор, и думал, что он мешал.

Оказалось, что накопилось слишком много "мёртвых" ключей (KMS получает ключ на 180 дней и периодически их обновляет).
И не смог активировать офис купленным ключом. Ну не сносить же из-за этого винду.

Решил проблему так:
Оперируем в окне Powershell с правами администратора:

irm https://get.activated.win | iex

Там выбираем 5 (Check activation status). В новом окне выведутся все ключи: и Windows, и Office, причем, на все продукты. Интересует значение строки Partial Product Key. Таких ключей может быть несколько. Окно не закрываем, понадобится позже.
Затем, в другом окне PowerShell, переходим в папку установки Office. У меня это C:\Program Files\Microsoft Office\Office16
По каждому ключу запускаем в этом окне:

cscript ospp.vbs /unpkey:xxxxx

xxxxx заменяем на ключ из окна с предыдущего шага.

После, в окне с ключами нажимаем любую кнопку, снова в окне активатора нажимаем 5. Если проработаны все ключи, то ключи Office не должны появляться. Если появились другие ключи (например, из-за переполнения буфера терминала), повторить. Но этих ключей быть не должно.

Затем, выйти из окна активатора, открыть Office. Дождаться окна с просьбой активировать, либо плашка "Нет лицензии". И спокойно ввести купленный ключ. И должно заработать

Опубликовал статью на Хабр по поводу библиотеки управления питанием

Ссылка: https://habr.com/ru/articles/986116/

Там же будут даны ссылки на репозитории и на библиотеку, и на демо-проект

Опубликовал компонент на IDF Components registry

И заметил любопытную вещь: если открывать страницу из России, и в репозитории есть README_RU.md, то он отображается по умолчанию

Компонент тут: https://components.espressif.com/components/dmitrij9992905/powermanagement-espidf/versions/1.0.2601~173/readme