Задался я вопросом, что лучше в плане энергоэффективности: много мегагерц и длинный сон, либо мало мегагерц и мало сна?
Провел лабораторную работу:

Получилось, что лучше работать медленно. А еще лучше, спать с малыми мегагерцами. Даже с отключенной периферией!
Отсюда возник вопрос: может я что делаю не так?
Судя по документации, WFI (без флага SLEEPDEEP в SCR) вырубает тактирование ядра. По здравой логике, если периферия отключена, ядро стоит, то и потреблять нечему. И общее потребление в Sleep режиме не должно зависеть от частоты....

А PLL по этой логике ничего не потребляет?

Потребляет. Примерно 3.3 мА.
Частота его постоянна, 288 Мгц. Остальные частоты получаются ее делением.
-------------
- Внешний резонатор, PLL выкл. 12 мГц - 9.4 мА
- Внешний резонатор, PLL вкл. 12 мГц - 12.7 мА
-------------

Не так давно ваял я батарейный девайс на LPC1758.
Так вот - я нашёл, что в моменты когда можно было спать (длительные интервалы неактивности), самым эффективным методом снижения потребления было перейти на IRC, выключить PLL, и выставить максимальный делитель (==256) на частоту CPU (ну естественно дать WFI, вся ненужная периверия отключена).
WFI у меня всегда выполняется в фоновой задаче даже когда ПО в активном состоянии - сама по себе WFI мало снижает потребление.
И более глубокие режимы сна я не мог использовать - UART1 должен был работать всегда.
Конкретных цифр потребления под рукой нет.

Что примерно укладывается в заявленные в даташите значения. Почему-то в нем не стали указывать потребление в обычном сне.
Для примера картинка от LPC13xx:

Как видно, потребление заметно меняется с частотой, несмотря на отключенное ядро и периферию.

какие то страшные цифры вы приводите. это ж какая батарейка должна быть? у нас потребление выше 30 микро и все за сердце хватаются.

Конкретные цифры я тоже получил. Даже с IRC/256 потребление порядка 1.5 мА. Для 15 кГц тактовой считаю это неприлично много. Для батарейного я бы выбрал другой камень.
При этом в SLEEPDEEP вышло около 0.6мА. Походу, сам IRC жрет чуть меньше 1 мА. И не отключить его... Возможность тактирования в этом случае от RTC бесполезна.


Вот и вопрос, что же во сне не засыпает, что так зависит от тактовой? Это особенности ядра CM3 или косяк NXP?

ЗЫ: Все бы можно было обойти, но LPC15XX невозможно реализовать динамическое изменение частоты ядра. Вся периферия тактируется через предделитель SCLK. То есть при изменении частоты ядра придется перестаивать всю периферию..

Я бы тоже. Только требование заказчика было: сделать из существующего (небатарейного) девайса батарейный с минимальными схемотехническими и программными переделками максимально быстро даже в ущерб потреблению. И однозначно не менять МК. Так что выжимал всё, что мог.
А в требования по ёмкости аккумулятора мы уложились даже с LPC1758, после переработки ПО в менее энергоёмкое и установки ключей на всю внешнюю периферию, которую можно отключить.


Если нет принципиально непрерывно работающей периферии, и алгоритм работы устройства позволяет, то это несложно. Я это и делал в LPC1758.

В том то и дело, что есть UART, на котором, к примеру, висит GSM. Он вроде и не постоянно работает, но потому он и асинхронным зовется, что нет никакой гарантии, что как раз в момент переинициализации не пойдет посылка..

В том-то и дело, что на таких девайсах как GSM (или BT-модуль как было в моём устройстве) как правило имеется аппаратный flowcontrol, готорый и даст Вам эту самую гарантию.