STM32F4, Динамическое изменение частоты ядра, Можно ли так делать? Опции

[Integro]

Всем привет,
Задача: добится минимального потребления, одна из идей смена частоты проца в засимости от режима работы.
Возможно ли это? Пробовал кто нибуть подобное? Если да, и это возможно, на какие грабли могу наступить? Детерминировано ли время настройки клоков? Я так понимаю придется дожидаться завершения всех транзакций передачи данных (I2C, SPI, DMA и тд) и перенастраивать переферию с учетом новых клоков?
Поправте меня если в чемто ошибаюсь.

P.S
Проц спать тоже будет, но и нужен режим когда нужно обеспечить какойто минимальный обмен.

Сообщение отредактировал Integro - Jan 19 2015, 15:08

[jcxz]

Задача: добится минимального потребления, одна из идей смена частоты проца в засимости от режима работы.

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

F4xx для этих нельзя, да и не зачем. Есть развитый слип для этого, тот же стоп. Все остальное от лукавого.

Не надо людей в заблуждение вводить. Останов одного только ядра CPU (WFE/WFI) даёт очень маленькое снижение потребления.
Так как остальная периферия продолжает работать и тактироваться.

Я делал работу с переключением (снижением тактовой) в периоды простоя в одном проекте, где была куча параллельно работающих задач с периферией
(несколько SSP+DMA каналов, UART+DMA, ADC+DMA, DAC+DMA), uCOS на LPC1758.
Всё прекрасно работает. Но в изучение работы периферии и ядра надо погружаться подробно, чтобы такое реализовать.
С поверхностными знаниями и пользуясь библиотеками такое думаю не сделать.

После останова и выключения всей периферии, перевода всех пинов в GPIO и установку на них соотв. состояний, я переводил тактирование
МК на внутренний IRC-генератор, выключал PLL, далее - устанавливал максимальный делитель тактовой IRC (==256).
В таком состоянии у меня МК и находился (IRC=12МГц/256).
Какой либо из режимов глубого сна с отключением тактирования в проекте использовать было нельзя, так как кроме основного генератора, другого
никакого не было, а пробуждаться надо было по таймеру, а не по внешнему сигналу.
Но даже в таком режиме, так как тактовая составляла всего порядка 47кГц, а периферия вся выкл., то потребление МК было очень маленькое.

Для выхода из этого режима, проделывал всё в обратном порядке.

[Сергей Борщ]

"минимального" - нет такого числа. Сколько в мА нужно?

Чем вызван такой интересный подход? Часто нужно как можно меньше. Чем меньше получится - тем лучше. Получится N mA - напишем в описании "время непрерывной работы K часов", получится X ma - напишем "Y часов". Чем больше часов сможем вписать - тем шире можно раздувать щеки перед потенциальными покупателями, особенно если у конкурентов это время меньше. И лучше сразу делать отрыв максимально возможным, потому что этот параметр может не являться основным и на его вылизывание в дальнейшем просто не дадут времени. И чем больше будет изначальный отрыв, тем дольше будет преимущество.

[jcxz]

Чем вызван такой интересный подход? Часто нужно как можно меньше. Чем меньше получится - тем лучше.

Тем, что всё чего-то стОит. Как правило: чем больше нужно получить эффект, тем больше нужно потратить усилий.
Внесение поддержки WFI/WFE даёт сколько-то процентов (скажем 20%) экономии энергии и сколько-то (немного)
усилий нужно потратить чтобы эту поддержку реализовать в фоновой задаче.
Алгоритм работы с каждым модулем периферии с отключением его в периоды бездействия - тоже траты на соотв.
организацию алгоритма, перепрограммирование периферии и т.п. Без этого ведь программа будет проще.
Ещё более глубокая экономия с использованием режимов всё более глубокого сна - всё больше и больше усилий и времени на разработку и отладку.