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

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

Можно. Есть же HSI генератор. Переключитесь на него, потом задайте новый режим PLL, дождитесь, когда установится, и переключитесь на PLL. Не забудьте про латентность флэш, но, так как она уже работала на высокой частоте, то и на низкой будет. Можно просто на HSI остаться. Там и низкоскоростной генератор есть, вроде. Все есть в руководсте.

А вот и нельзя, так делать никогда. На мелких простеньких процах сойдёт но не с F4xx. Не стоит наступать на понятные грабли. Дожидаться завершения всех транзакций передачи данных (I2C, SPI, DMA и тд) и перенастраивать переферию с учетом новых клоков не детерминировано. А та облась памяти озу в F4xx, которая не доступна, что с ней? и еще кучка. Давно есть другой способ, нечего делать процу, остановили его и ждем. Тактовая нуль, жёр почти нуль, чёт дёрнулось, и мы уже на коне, не надо никого перенастраивать, искать и добавлять туда глюков ну и тд.

А когда процессор запускается, не страшно?

Не страшно, в F4xx все выполняют команду - стоять, бояться.
И чего по вашему может быть страшного в этом M-4F кортексе?

Вот и я так думаю. А что же вы людей пугаете Кортексом?

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

Кстати еще иногда для периферии можно выбрать источник клока, то есть ее можно всю оставить на большом клоке, а само ядро уронить на маленький, нет?

F4xx для этих нельзя, да и не зачем. Есть развитый слип для этого, тот же стоп. Все остальное от лукавого. Думаю, что много лет назад создатели чипов обсуждали без нас эту недерминированность. Аккуратненько не получается, просто берете на себя целый ряд рисков с непонятным обслуживанием, доп буферированием и тд, непонятно для чего то занять кусок памяти, которой может и не быть. И что, вам без этого мало глюков и багов в программах? Анекдот про неглючную прогу знаете?


Чтоб матчасть хорошо знали без перевода.

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


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

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

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

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

Исходя из описания видно, что можно значительно менять тактовые процессора и периферии. Но, как уже писали запуск кварца, запуск PLL это длительные события. Плюс ожидание завершения операций и обратная инициализация.
Очевидно, что такой режим работы применим в редких случаях, а не как стандартный. Всётаки лучше задействовать один из режимов сна с отключением ненужной периферии. Если это не устраивает, то лучше посмотреть на двух-ядерные процы. Например у NXP есть M4F+M0. Там можно усыплять к примеру M4F и работать с M0.

Ситуация "спит - проснулся - быстро сделал дело - уснул" понятна, популярно описывается, например, для MSP430.
А можно придумать ситуацию, где "медленно и методично выполняет свою работу" будет лучше?

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

Как это маленькое снижение потребления, еще какое большое. Думать то надо со 180Мгц в ноль. Сколько это по вашему маленькое? Еще какое большое. Ток когда нибудь тестором меряли? Похоже нет. По этому не нужно врать. Периферия как потребляла так и потребляет, все инжины маложрущие. Куча параллельно работающих задач с периферией и это как же так без либ? Короче смами себе противоречите.
Ну а сертификацию такая программа точно не пройдет.

Не обосновано грубо и ровно также не верно.
Сертификацию на что? На взрывозащиту? Гигиенический сертификат? По каким параметрам она не пройдет? Вот про сертификацию как раз лажа...

Я что-то с сертификацией тоже не понял. О чём речь? Например у меня сертификация средств измерения. Я и не думал никого в известность ставить как там мой процессор работает. Спит он или нет, за сколько времени просыпается. Главное чтобы прибор соответствовал своему описанию и обеспечивал измерения с заданной точностью, а также вычисления с заданной регулярностью и так далее.

лажа...пока у вас в сообщении. Похоже на то, что ничего не знаете о сертификации программного подукта и программ.
Начните с этого: http://www.nspru.ru/sertsoftware/ ... и далее.


Да я смотрю, что вы новичёк в этой софтверной сертификации. Для вас главное чтобы прибор. Ан нет, еще и сертификацию проги загружаемой нужно пройти и доказать много чего ещё.

А вы видать гуро... сколько ТУ на сертификацию написали или так краем уха слышали ?

смешно ей богу, сертифицировать можно что угодно, можно сказать что ваш прибор весит не больше 1 кг, и получить на это сертификат, и как тут программа сработает?

А в сертификации средств измерения кроме точности надо доказывать защищенность от внесения изменения в программу и калибровочные коэффициенты, но никоем образом не показывает алгоритм ее работы в сфере энергопотребления.

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


По теме сообщения-------------------
Можно проц запустить полноценно работающим на низкой частоте (полноценно для данного режима энергопотребления)? - можно
Можно запустит на высокой - можно

Что теперь если проц грузиться всегда на низкой, а по команде переходить на высокую? тогда можно для перехода с высокой на низкую - просто вызывать сброс проца. И все будет славненько работать, без каких либо недерменированостей.

А процедуру ресета можно и руками провести, переведя все регистры в начальное состояние.

Другими словами переход на высокую и низкую частоту никаким образом не вызывает неопределенностей, если сделать все аккуратно

Более того. Я ввожу понятие "Метрологически значимая часть ПО". Далее, в приборе, вывожу две контрольные суммы на метрологически значимую и полную. И, в целом, это позволяет мне обновлять ПО.
Но если глубоко копать, то всё это бред, которого просто море .... Наши и Ваши чиновники пытаются взять контроль над всем миром. Да документ позволяет многое, в том числе и "экспертный анализ" исходников ... Можно этот документ, как саблю, поднять над головой и размахивать. А можно сходить в нужник и пустить его по назначению. Там ему и место.
Моё глубокое убеждение, что качество продукта обеспечивает ТОЛЬКО производитель. И сертификат чистейшей воды фикция.
Ну не работает у тебя прибор. Ты куда в орган выдавший сертификат пойдёшь?
Или ещё один пример.
Вот крыша в Трансвааль парке обрушилась... Вот тебе лицензии на строительные работы, вот сертификаты на стройматериалы, вот проект завизированный главным архитектором. И что? Кто виноват? К кому обращаться? В цивилизованном обществе надо было судится со строительной организацией. А уж она там пускай разбирается, или проект плохо сделали, или металл некачественный поставили или дядя Петя неквалифицированно кладку положил. Условно говоря.
Вы когда на BMW садитесь, за сертификат не беспокоитесь. И так во всём!

В цивилизованном мире крыши тоже рушатся. По Дискавери показывали. И причины те же - неправильно рассчитали, не те материалы применили, и т.д.
Если сертификация программ хоть немного улучшит положение с плохо взлетающими космическими аппаратами, то пусть будет.
Я плохо представляю критерии, по которым будут оценивать программу. Точнее, качество оценок по этим критериям.

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

У меня для одного изделия быстродействия особо большого не требовалось, STM32F2 работал на 4МГц, но подключаясь к USB надо было разгоняться до 16МГц (иначе USB не работает). Никакие PLL не перенастраивал. Играл только делителями. Главное, чтобы не нарушать скорости USART, I2C, SPI - поддерживать частоты на шинах постоянными. В данном случае APB1 и APB2 держал на 4МГц.

Что - в ноль? Частота CPU? После выполнения команд WFI/WFE?
Не порите чушь!
После выполнения WFI/WFE частота CPU никак не изменяется. Останавливается только ядро. Всё остальное продолжает работать на той-же частоте.
И снижение потребления по моим наблюдениям на LPC17xx порядка 20%.


Какая связь между либами и сертификацией?


Гура... одним мановением команды WFE частоту процессора от 0 до 180МГц меняет.
А вы тут про какие-то задержки на старт/стоп PLL толчёте. Лошары!!
Иээх! Завтра пойду - метрологов наших обрадую - пообещаю какую-нить завалящую либу в ПО воткнуть - сразу у их сертификация на ура пройдёт, а то они, дурни, с ЭМС всё маются...



Глубоко и полностью согласен с Вами, коллега!


Во-во. У меня тоже в одном девайсе нужно было питаться от аккума (с выкл. PLL для экономии и делением на 2 частоты кварца и периодическим уходом в более глубокий "псевдосон" включением
делителя частоты на 256), а при подключении к USB - включать PLL чтобы обеспечить минимальную нужную ему частоту.
PLL - один из самых жрущих узлов в МК между прочим.

Всем спасибо за ответы.
Если кому интересно, по теме...
Использую FreeRTOS, при смене частоты блокирую переключалку задач, далее пользуя функции кубовского hal, RCC_DeInit(), затем стандартный инит клоков с новыми делителями, потом инициализация периферии.
На ре-инициализацию клока уходит меньше миллисекунды.
Потребление с частоты 84Mhz до 24Mhz уменьшается на 10 мА (грубая оценка, камень STM32f401 питается через DC-DC 1.8v).

На данный момент работает стабильно, глюков не обнаружено.
Из переферии после смены клоков работало все кроме UART, понятно, уплыла скорость.
Шины I2C и SPI можно не ре-инициализировать, работали на меньшей скорости.

Интересно - как Вы измерили? По часам, которые переинициализируете?


Переинициализировать по уму нужно всё, на что влияет частота тактирования. Чтобы потом не было неприятных сюрпризов.
Также, в процессе перехода, данную периферию нужно отключать.

дернул джипио


так и делаю, но в рамках эксперемента, работало без реинициализации

что логично, SPI и I2C они же клоки выдают, это тупые автоматы, они не уарт который ко времени привязан, так что логично что они без переинициализации дальше поехали, выключить их как бы чего не вышло стоит, конечно, но думаю можно даже пока байт передается частоту перебросить, справятся, я в них верю!)