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

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

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

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

Сообщение отредактировал startrek77 - Aug 4 2010, 21:45

Да, можно. Для ранних серий (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) и обратно без проблем. А вот встала задача банально уменьшить тактовую вдвое на время и что-то лажа выходит...