ARM, RISC-V контроллеры

Смысл сообщения я не понял. Экономия единиц-десятка миллиампер в цепи 3в (работающий генератор) оправдана? Чтоб она была оправдана нужно вначале всю прочую схемотехнику вылизывать. Опять же источник питания (с низким КПД), резисторные делители (подтяжки) в входных/выходных цепях и т.п. Я не уверен, что у тебя к тому подошло уже. Софт тоже: должен уметь усыплять ядро (cpu) когда не нужно, отключать неиспользуемые модули, усыплять внешние модули и микросхемы. Зато вот 

приключения с остановкой всей периферии на мой взгляд космические, начиная с таймера (а как отрабатывать события привязанные к времени???) Я не понимаю, зачем побудка по прерыванию. Такие решения приемлемы в очень простых приборах, где у МК ровно одна функция. Когда функций много -- будут конфликты.

Про "весёлые вещи" тоже ничего не понял. Если останавливать периферию, понятно, сообщения будут потеряны. Поэтому после любой остановки нужно командами опрашивать статус всех подсистем модема. Если какую-то информацию опросом не получить (доступна только через unsolicited сообщения) -- то вариант с остановкой периферии вообще не вариант. Если речь о том, что частота внутреннего генератора уплывает -- ну так он ж периодически, раз в пару секунд, например, подстраиваться должен. Всегда. А не однократно когда-то.

Остановка CPU (не всего контроллера, генератора, периферии, а только выполнение команды WFI ядром) тоже сложная задача. Здесь уже больше для программиста. Работа с периферией требующей реакции должна вестись по прерыванию. Обязательно нужен таймер запрограммированный на периодическое (простой вариант) или на пробуждение в нужный момент времени. Нужен какой-то планировщик задач или, на худой конец, big loop. Если OS, то у ней должна быть предусмотрена idle task с выполнением WFI. Если BigLoop, то какой-то механизм принятия решения, мол события закончились и можно заснуть (до прерывания или срабатывания таймера). Сам код ещё должен быть так написан, чтоб не содержать циклов с проверкой условий в циклах (вместо этого нужно использовать событийные механизмы ОС или какие-то полумеры в bigloop). И здесь неэффективно энергии может быть потрачено куда больше, чем на постоянно работающий тактовый генератор.

Про big loop я когда-то писал: http://caxapa.ru/279767/, про таймеры недавно топик был: http://caxapa.ru/1046507/ (там другие сообщения то