Я работаю с AT91SAM7S256. Частота работы настроена на 48 мегагерц для USB. Но так как устройство портативное, то потребление слишком высокое.
Я планирую работать на частоте к примеру 8 мегагерц (или 16 мегагерц) и только в те моменты когда подключено USB переключать процессор на частоту 48 мегагерц.

Сейчас код отлажен на частоте 48 мегагерц. Крутится фриртос.
Вопрос, вообще можно ли стабильно работать с этим процессором переключая частоты в реальном времени? Если да то на какие моменты обратить внимание?

И ещё, так как это фриртос, то как вы считаете отлаженный код на 48 мегагерцах должен хорошо адаптироваться на частоту 8/16 мегагерц?

И ещё такой вопрос. Может ли ядро быть настроено на 8 мегагерц а USB на 48 и работать одновременно, что бы частоты не переключать?

Да, можно. Для ранних серий (58818C) следует обратить внимание на еррату.


Ну, если ему будет достаточно 8/16, то какие могут быть проблемы? Разве что перепрограммировать всю частотнозависимую периферию при переключении клока не слишком удобно может показаться.

Idle-режим уже задействовали? Если нет, то начинать стоит именно с него.


Увы, нет.

А Idle-режим это что такое? Никогда не сталкивался, поясните


Я вот картинку приложил. Там написано что при "ARM core clock 8 Mhz" и "USB transceiver enabled" потребление будет ~8,4 мА.
Получается частота ядра 8 мегагерц одновременно с настроенным USB. Разве нельзя PLL настроить на 48 мегагерц (USB должно работать) а ядро процессора настроить к примеру на 12 мегагрц настроив делитель? Т.е для ядра поделить частоту PLL поделить на какое-то значение, я про параметр PMC_MCKR.

Остановка ядра до получения сброса или прерывания. см. 25.3 Processor Clock Controller


Пардон, стормозил. 8 можно получить только с кварцем на 8, а вот 6 или 12 свободно делителем.

Её получается можно использовать когда мы точно уверены, что код в основном теле программы не будет выполнятся до любого прерывания. Вы не подскажите где во фриртосе может быть такого состояние?

Во FreeRTOS есть Idle Task и IdleTaskHook().

получается в vApplicationIdleHook просто написать строчку AT91C_BASE_PMC->PMC_SCDR = AT91C_PMC_PCK;
Правильно я вас понял?

Да, теоретически этого должно быть достаточно.

Такс проверим практически после отпуска.
Првда в частно случае такая маинация может вообще не дать прироста результата если модуль в идл не попадает.

Если не попадает, значит процессор загружен на 100%, но тогда и снижение частоты явно не пройдет незамеченным (сломается/затормозит).

Итак, какие методы оптимизации по потребления я для себя усек.
1. Снизить часту работы ядра до 6 или 12 мегагерц.
2. В идл таске фриртоса написать перевод процессора в idle-режим (AT91C_BASE_PMC->PMC_SCDR = AT91C_PMC_PCK;)
3. Частоту тиков я тоже уменьшу с 1000 до 100 раз в секунду.


Что ещё можете подсказать с методов оптимизации по потреблению???

п.3 заметно сказаться на потреблении не должен.


Остальные методы все стандартные:
- выключить лишнюю периферию
- проверить, нет ли где избыточного потребления по GPIO (тоже на еррату надо обратить внимание)
- оптимизировать ПО

Как скажется изменение значения делителя (PRES) в PMC_MCKR на принимаемых по ДМА данных в AT91SAM7S256(ABC)?

Интересует два момента:
1. В момент переключения не будет ли сбоя.
2. Может ли частота MCK вообще быть ниже частоты принимаемых по ДМА данных?

1. Никогда не наблюдал каких-либо сбоев при корректно выполненном переключении.
2. Не совсем понял вопрос. MCK - частота процессора, шин, периферии. Как она может быть ниже "частоты принимаемых по ДМА данных"?

Здесь есть 2 нюанса:
1. Я не увидел ни в даташитах, ни в примерах, хоть пол-слова упоминания что я должен сделать когда источник тактов не меняется, а меняется лишь делитель.
Фактическт выходит, что я могу менять значение PRES в PMC_MCKR на лету в любой момент времени, и частота работы ядра изменится на следующей инструкции, даже флаг проверять не надо!

2. Если я меняю источник тактирования, например с PLL на SCLK, то пока это всё запускается/лочится - у меня есть простой по MCK, соответственно в эти микросекунды переферия не тактируется и не работает.
Т.е. переключить-то можно корректно, просто можно данные потерять, если прос ведомый!
До сих пор я переключал тактовую лишь во время смены режима работы всего устройства, фактически это были не связанные задачи с полной переинициализацией периферии.
Сейчас встала задача снижать MCK при непрерывно работающем DMA и пока оно не работает.
Может МК дурит, может в коде ошибка. Но тенденция настораживает, а обсудить не с кем



Банально: SSC в режиме внешнего тактирования (ведомый), принимает данные в ОЗУ по DMA через RF,RK,RD со скоростью 300кбит, кто мне мешает установить MCK, хоть в 500Гц?

Я раньше не пробовал подобные финты - сейчас попробовал - и обломался.
Банально не могу менять значение PRES.
Раньше переключался SCLK->PLL(MCK) и обратно без проблем. А вот встала задача банально уменьшить тактовую вдвое на время и что-то лажа выходит...

В даташите:



По поводу простоя обратите внимание на текст в 25.8.1 Master Clock Switching Timings.
Если прескалер включен, то ко времени переключения нужно прибавить еще 64 такта нового клока.


Опять же даташит:

Я хочу менять лишь значения прескалера у MCK. Как это сделать в даташите не описано, на диаграмах такой вариант не показан и в примерах кода - его нет.
Интересует именно эта процедура и её последствия на работу ДМА в режиме ведомого.
Как по вашему мнению - принимая данные на RK,RD со скоростью 300кбит я могу поменять MCK с 30МГц на 1МГц, а затем обратно при помощи прескалера?
Или данные будут потеряны, а синхронизация собьётся?
Фраз о том, что в момент смены делителя частоты я должен отключить всю переферию, а затем включить и переинициализировать заново - я не нашел.


Там же: Each time PMC_MCKR is written to define a new Master Clock, the MCKRDY bit is cleared in PMC_SR. It reads 0 until the Master Clock is established. Then, the MCKRDY bit is set and can trigger an interrupt to the processor. This feature is useful when switching from a high-speed clock to a lower one to inform the software when the change is actually done.

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


А если я не меняю источник, а хочу лишь изменить делитель - прескалер то мне всё равно ждать 64 такта нового клока?


Получается, что как минимум на Main Clock никто не мешает мне просто обновлять значение PRES и в соответствии
с таблицей 25-1. Clock Switching Timings (Worst Case): From Main Clock To Main Clock время переключения будет равно прочерку.
Что это значит - я не знаю, то ли так нельзя переключаться, толи переключение произойдёт мгновенно.

С режимом PLL Clock тоже не понятно. Или я должен записать в PRES новое значение и выждав MCKRDY, зачем-то опять записать в CSS то же число.
Или изменение PRES не возможно без изменения частоты PLL.

Повторяю: я не хочу менять источник частоты. Лишь его делитель. Как же коряво нужно создать кристалл, чтоб при изменении делителя происходил пропуск частоты или происходил её перезахват и нужно было ресетить всю систему? Неужели всё так хреново у Атмела?

У Вас по-любому поток по I2S сломается, если не поллить клок и не переключаться в его середине.

Это из практики или предположение?

Вообще-то, есть варианты:
1. если приёмник тактируется от I2S, а не смотрит значения на входах тактируясь от MCK - то не надо поллить.
2. если смена частоты MCK происходит сразу или без пропусков длинее 2мкс (для 300кбит).

А вот как оно там происходит с MCK - пока непонятки...

Этот момент не ясен, надо проводить лабораторную работу для уточнения.


Ограничение частоты по MCK/2 явно указывает, что имеет место синхронизация с MCK.

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