Страница 1 из 1

Критерии выбора тактовой частоты МК

Добавлено: Пн окт 27, 2008 20:53:31
sachok
Я начинающий в программировании поэтому мне интересно как правильно выбирать тактовую частоту для МК.

Добавлено: Пн окт 27, 2008 20:58:11
tych
Я рекомендую в курсе для начинающих AVR-щиков выбирать минимально возможную тактовую частоту - позволяющую гарантировано выполнить тех задание на устройство.

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

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

Высокая тактовая частота дает больше возможностей для чисто софтовой модификации устройства если его память забита разумно (на мой взгляд конечно) - т.е. не более чем на 60-80 процентов.

Добавлено: Вт окт 28, 2008 05:19:56
MOHOXPOM
Я бы посоветовал выбрать максимальную частоту кварца по табличке настройки UBRR для подходящей скорости ком порта (BAUDRATE) и при минимальной ошибке обмена на данной скорости.

Добавлено: Вт окт 28, 2008 06:41:10
Migray
Все зависит от задачи.

Это главное правило.

Если в задаче необходимы вычисления - выбираешь максимальную частоту.
То-же самое придется сделать при необходимости быстрой реакции на какие-то события.
Про это писал tych

При необходимости безошибочной связи с другими устройствами - выбирай скорость, позволяющую уменьшить погрешность, как посоветовал MOHOXPOM

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

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

То-же самое можно делать в автономных распределенных системах, скажем в сигнализации.
Пока нет обмена по сети, проц может лениво опрашивать пару портов.
Пришел запрос на обмен данными - "встрепенулся", отрапортовал, и дальше опять спешить не надо :)