Вообще dc/dc на малой нагрузке обычно не очень хорошо работают (это видно по графикам efficiency). Если нужно маленькое потребление без нагрузки, можно поискать low Iq (quiescent current) регулятор

у меня МК в power-off mode после него должен был стоять. Но видимо надо что-то другое искать (опять). 8мА схавают аккумулятор за несколько дней (1600mAh чуть дольше, но все же)

Погугли low iq buck, можно найти модели, которые потребляют единицы мкА и меньше при малой нагрузке

Я правильно пониамю. Они потребляют +- 12uA и если вдруг нагрузка увеличивается( просыпается МК) оно само начинает работать?
Потому что я скинул выше, оно в спящем ружиме всего 1uA кушает, но я не могу управлять спящим режимом, потому что ом управляет МК, который не сможет проснуться без питания 😄

Хотя бужу МК я по кнопке. Если как-то эту кнопку сразу и к микросхеме и к МК прицепить..

Не понял, откуда цифра 12 uA.

Самый простой вариант - поставить кнопку с двумя состояниями, и напрямую управлять ножкой EN, имхо

Что если так? Когда нажимаем, просыпается конвертор, включается МК и сразу ставит GPIOx в HIGH. Будет ли это работать и смогу ли я потом тыкать кнопку в рабочем состоянии? :)

Это про iq buck. Нашел от TI и там просто 12 написанно.

Хотя все фигня. Смысл мне будить МК, если он без питания 🙂 Можно на любой пин кидать кнопку

Фигня какая-то. вывел EN на MP2307 на кнопку. В выключенном состоянии все равно модуль 5мА кушает. ДАташит врет?
В нем вообще указанно что максимальное это 1.5мА

В datasheet не приведены данные утечек по конденсаторам. Или у тебя везде керамика?

У меня готовый модуль. В нем керамика

Тогда хз )
Подумай что там может быть кроме quescent current )

ДА кажись там само-срабатывание. Надо подтяжку к земле сделать

Почему reinterpret_cast может внезапно возвращать nullptr? Сталкивался ли кто-нибудь с эдаким?

Немного больше контекста:
Я работаю с буфером OpenGL -- загружаю в его кусок генерируемые вершины. Для экономии пропускной способности я хитрым образом кеширую кусок буфера в передвигающемся окне, которое представлено как std::vector<uint8_t>, поскольку так удобнее считать смещения при работе с отображенным на ram буфером через c-интерфейс.

Однако, в остальной программе удобнее работать с массивом float-ов (в виде которых представлены вершины). Поэтому у меня есть метод, в котором к window.data() прибавляется смещение, а затем получившийся uint8_t* reinterpret_cast'ится к float*.

При этом, в один момент, на вид не связанный ни с чем другим, reinterpret_cast внезапно превращает указатель в null, что закономерно приводит у сегфолту. Выравнивание в норме (остаток от деления на sizeof(float) = 0).

Не понимаю, почему такое может происходить. Может у кого-то есть идеи?

каст флоатов рисковая затея

вы там не создаёте недопустимое для флоата значение?

Значит и оригинальный указатель nullptr

Не должен. К тому же, кастую я к указателю, который содержит зануленную память.