Преднамеренное изменение тактовой частоты МК Опции

[=GM=]

Народ, вот такой вопрос. Будет ли нормально работать МК, если тактовая частота будет меняться в некоторых пределах, скажем, 20%?

[_dem]

А почему нет ?

Подача частоты с внешнего генератора ?

[Methane]

Народ, вот такой вопрос. Будет ли нормально работать МК, если тактовая частота будет меняться в некоторых пределах, скажем, 20%?

А чего нет? Я лично проблем не вижу. Главное чтобы импульсы были не "короче чем"

[Rst7]

Народ, вот такой вопрос. Будет ли нормально работать МК, если тактовая частота будет меняться в некоторых пределах, скажем, 20%?

Хороший вопрос. В даташитах по этому поводу сказано, что не более чем на 2% от цикла к циклу. Как это согласуется с уверениями о полностью статическом дизайне - я не понимаю.

Предлагаю этот вопрос задать Атмелу. Кто напишет на вменяемом английском туда запрос? Потому что я за собой замечаю, что пишу явную ахинею - в языковом смысле. Хуже Гоги, торгующего шаурмой

=GM=
Профессионал
Group: Свой
Posts: 1 122
Joined: 22-06-06
From: Oxford, UK
Member No.: 18 282

Бугага. Вот кто напишет

[=GM=]

Подача частоты с внешнего генератора?

Ну да. У меня оформились две идеи по использованию. Одна из них - программный high speed USB 12 МГц.

Бугага. Вот кто напишет

Чёрт, даже в голову не приходило, мне проще позвонить и спросить...если они отвечают по телефону.

[galjoen]

Хороший вопрос. В даташитах по этому поводу сказано, что не более чем на 2% от цикла к циклу.
...

В описании на те процессоры, у которых есть регистр XDIV (ATmega64...), написано, что после изменения тактовой частоты (записи в XDIV) нужно выполнить 8 NOP-ов. Иначе команды могут неправильно воспринятся.
Отсюда можно предположить, что там какая-то проблемма с конвейерами...

[Rst7]

Чёрт, даже в голову не приходило, мне проще позвонить и спросить...если они отвечают по телефону.

Сомневаюсь. Лучше напишите. А потом не забудьте поделиться с нами ответом. Потому что например меня этот вопрос тоже интересует. Больше, правда, в теоретическом плане - можно или нет кормить камень прерываемым клоком?

[=GM=]

В описании на те процессоры, у которых есть регистр XDIV (ATmega64...), написано, что после изменения тактовой частоты (записи в XDIV) нужно выполнить 8 NOP-ов. Иначе команды могут неправильно восприняться. Отсюда можно предположить, что там какая-то проблема с конвейерами...

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

Мой же вопрос не о подаче глитчей в цепь клока, а об изменении периода клока, скажем, была частота 5 МГц, соответственно высокий и низкий уровень были по 100 нс, и вдруг после низкого уровня идёт высокий длиной 80 нс, т.е. изменилась частота клока. Ну, это в пределе, а в реале должно быть более плавно.

[galjoen]

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

Если дело обстояло бы так, то всего 2-х NOP-ов было бы достаточно, а там именно 8. И не 64, как было бы в худшем случае. И кстати почему тогда бы NOP не мог бы воспринятся/считаться неправильно? А в описании написано, что NOP-ы точно правильно воспримутся. Кстати появилось это только в последних версиях ДШ. Напоролись на глюк?

[fmdost]

...что там какая-то проблемма с конвейерами...

Бутылки с них скатываются?

В даташитах раньше был оговорен парамерт "скважность синхроимпульса". Но это на МОП. На КМОП наверное можно.

[domowoj]

Вопрос вдогонку профессионалам.

Как быстро установится внутренний RC генератор при изменении содержимого OSCCAL?

[Rst7]

В даташитах раньше был оговорен парамерт "скважность синхроимпульса". Но это на МОП.

Дык когда деревья были большими, регистры были на конденсаторах. Вот и ограничивали и частоту снизу (пример - 8080). И дизайн был рукопашный, извращались как могли, вот и приходилось ограничивать время нахождения в одном состоянии (пример - Z80, там в одном состоянии тактового сигнала можно было вечно сидеть, а в другом - ограниченно).

Но тут на первой странице большими буквами про полностью статический дизайн. А потом про ограничения. Нифига не ясно.

[Rst7]

Как быстро установится внутренний RC генератор при изменении содержимого OSCCAL?

Поставьте эксперимент. Скорее всего - в следующем такте. Кстати, на изменение OSCCAL тоже наложено ограничение в +-2% частоты за раз.

Только вот.... Помнится мне одна фигня.... Щас гляну....

Неа... Погорячился я с ограничением на OSCCAL. Нету. Да и в "AVR053: Calibration of the internal RC oscillator" в полный рост бинарный поиск. Т.е. значение OSCCAL за раз может измениться аж на четверть диапазона. При этом, после записи в OSCCAL нового значения стоит 2 NOP'а.

[=GM=]

Если дело обстояло бы так, то всего 2-х NOP-ов было бы достаточно, а там именно 8. И не 64, как было бы в худшем случае. И кстати почему тогда бы NOP не мог бы воспринятся/считаться неправильно? А в описании написано, что NOP-ы точно правильно воспримутся

1) Как я понимаю, там стоит предделитель клока на 2-129, ну вот и надо его весь заполнить перед новым использованием. А то может получиться так, что в хвосте регистра остались все единицы и первый же фронт приведет к смене фазы клока.

2) Здесь нопы выступают как бы безопасной программной задержкой. По нопу делается холостая операция, что значит, правильно или неправильно воспримутся? Если будет глитч, ноп просто не прочитается, ну и ничего страшного, от нопа не ждут никакого действия. Страшнее будет, если реальная команда не исполнится, или, если команда двухсловная, вы пропускаете первую половину команды и попадаете на вторую половину команды...

[fmdost]

...от нопа не ждут никакого действия. Страшнее будет, если реальная команда не исполнится, ...

NOP такая-же команда как и остальные. Непонятно почему NOP вдруг выполнится правильно, а MOV неправильно. И непонятно почему в результате глитча NOP вдруг случайно не станет MOV.
Чёта эти атмеловцы тут недогаваривают, однозначно

[-=TRO=-]

Думаю тут дело не в правильной интерпритации команды, а в неискаженных данных которыми оперирует команды. NOP ни с чем не взаимодействует, тупо ждёт. Остальные команды как минимум читают или пишут в регистры, и как максимум дёргают внутреннюю переферию.

[Rst7]

Чёрт, даже в голову не приходило, мне проще позвонить и спросить...если они отвечают по телефону.

Ну что, нет ли у Вас каких-либо известий? Или забили на это дело?

[=GM=]

Да не то, что забил... Полазил по описаниям, так и есть, как вы сказали, т.е. допускается плюс-минус 2% от такта к такту, далее там говорится "изменение частоты более чем на 2% может привести к непредсказуемому поведению, поэтому требуется держать МК в ресете во время смены клока".

Ну и в связи с этим, неохота мне задавать вопрос в атмеловской поддержке, чтобы нарваться на такой очевидный ответ, и прослыть ugly customer (жутким субъектом) (:-). Комизм ещё и в том, что они не поймут, что частоту качать на 20% нужно для создания ФАПЧ на самом микроконтроллере, это выходит за рамки их разумения.

Ну да ладно, я решил задачу по-другому, теперь могу принимать данные с USB аппаратно с помощью SPI, проц 50% времени свободен.

[Rst7]

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

А Вы его не так задайте. Вы спросите - "как согласуется утверждение о полностью статическом дизайне на первой странице и требование +-2%? Могу ли я, согласно первого утверждения тактировать МК от кнопки?"

[Nanobyte]

А Вы его не так задайте. Вы спросите - "как согласуется утверждение о полностью статическом дизайне на первой странице и требование +-2%? Могу ли я, согласно первого утверждения тактировать МК от кнопки?"

Сдаётся мне, полностью согласуется. Беглый взгляд на временнЫе диаграммы в любом DS показывает, что для внутренней синхронизации используются не только основная частота CLKcpu, но и её "версии" с различной задержкой, т.е. выполнение команд по времени разбито на части, гораздо меньшие периода входного синхросигнала.
Поэтому при резком изменении Fclk возможна ситуация, когда последовательность появления фронтов/спадов внутренних сигналов МК будет нарушена и, например, МК попытается прочитать данные до того, как устаканится адрес, "хвост" команды обгонит "голову".
ИМХО, для создания этих задержек используются RC-цепи.
Ну, а при медленном изменении тактовой частоты, границы между внутренними синхросигналами не расползаются, и все работает ОК.

[Rst7]

Беглый взгляд на временнЫе диаграммы в любом DS показывает, что для внутренней синхронизации используются не только основная частота CLKcpu, но и её "версии" с различной задержкой, т.е. выполнение команд по времени разбито на части, гораздо меньшие периода входного синхросигнала.

Да ну? Где-же Вы это "бегло увидели"?

[Nanobyte]

Да ну? Где-же Вы это "бегло увидели"?

Ну да! Например в DS на Мегу128:

Figure 7 Single Cycle ALU Operation,
Figure10 On-chip Data Sram Access Cycles
Figure13 External Data Memory Cycles
Figure156 External Memory Timing

У меня, конечно глаз - не осциллограф, но всё-же ...

[Rst7]

Ну так вот насчет обычной Figure 7 - никаких задержек для выполнения тут не нужно. Если после фронта сигнала CLK будет зафиксирован адрес чтения, то через некоторое время данные появятся на выходе двухпортового регистра, затем пройдут через сумматор и по следующему фронту CLK зафиксируются обратно в памяти.
Остальное тоже без всяких задержек делается. Что-то мне вообще подсказывает, что тут дело в контроллере флеша. Там, видимо, какие-то из..бы.

[Maik-vs]

Сдаётся мне, полностью согласуется. Беглый взгляд на временнЫе диаграммы в любом DS показывает, что для внутренней синхронизации используются не только основная частота CLKcpu, но и её "версии" с различной задержкой, т.е. выполнение команд по времени разбито на части, гораздо меньшие периода входного синхросигнала.
Поэтому при резком изменении Fclk возможна ситуация, когда последовательность появления фронтов/спадов внутренних сигналов МК будет нарушена и, например, МК попытается прочитать данные до того, как устаканится адрес, "хвост" команды обгонит "голову".
ИМХО, для создания этих задержек используются RC-цепи.

Если так, то задержки фиксированны и "хвост" успевает закончится до начала "головы" при максимальной тактовой. А вот если дополнительные синхросигналы образуются за счёт умножения тактовой каким-нибудь PLL-ем, то да. Причём и в случае резкого понижения тактовой PLL может слетать. Хотя тогда вопрос "могу ли я тактировать кнопкой" особенно интересен.
Аж руки зачесались попробовать минимальную тактовую... времени нету пока.

[=GM=]

Вы спросите - "как согласуется утверждение о полностью статическом дизайне на первой странице и требование +-2%? Могу ли я, согласно первого утверждения тактировать МК от кнопки?"

В принципе это два разных вопроса, не совсем понятно, как вы их связываете друг с другом, но на оба вопроса есть ответ в дейташите.

1) Пмсм под полностью статическим дизайном у них, у атмельцев, подразумевается, что ВСЕ регистры проца не динамические, а статические. Отсюда следует, что теоретически тактовая частота начинается от нуля, что ОТРАЖЕНО в описании. И вы можете тактировать МК от кнопки, раз в год (31 июля) тактируя свой аппарат, правда, такое нафик никому не нужно, но теоретически допустимо.

2) На второй вопрос, какова допустимая скорость изменения периода клока, дан чёткий ответ: плюс-минус 2% от одного клока до другого, если больше, то будьте добры поставить проц в состояние ресет. Почему так - непонятно, но ответ есть.

[Rst7]

Особенно интересен момент старта из глубокой спячки всего за 6 тактов. PLL, говорите? Слишком уж частота среза фильтра в обратной связи должна быть высокая... Аж такая, что и фильтра не надо А, значит, и PLL так себе получается...

В принципе это два разных вопроса, не совсем понятно, как вы их связываете друг с другом

Полностью статический дизайн подразумевает, что ограничивается только период CLK (мин. значение), время нахождения его в состоянии 0 и в состоянии 1 (тоже мин. значение). В сторону максимума - любое.

Это и записано в Clock Characteristics/External Clock Drive. Но еще эти 2%... Вот тут уже совсем непонятно.

[=GM=]

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

[Rst7]

так что спрашивать у техподдержки нечего

Уговорили. Спрошу сам

[=GM=]

Дело теперь за немногим,
Нужно натуры живой,
Глядь, симпатичные ноги
Гордо идут с головой
(С) ВСВ

Удачи вам, Дмитрий!

Если нужна помощь в переводе или обсуждении перевода, обращайтесь.
Глядишь, впоследствии вам присвоят следующее звание Rst7.5(:-)

[Dog Pawlowa]

Мда...
Я как-то применил ( причем украденую у кого-то! ) идею использовать частоту с выхода контроллера CAN для AVR. Все работало, но черт меня дернул посмотреть даташит.
Учитывая, что прибор стоит кучу денег и продается штучно по всему миру, поставил второй кварц и сплю спокойно.
Не задаваясь лишними вопросами

[Rst7]

идею использовать частоту с выхода контроллера CAN для AVR

Это немного не то. Контроллер CAN дал Вам просто поделенную частоту своего кварцевого генератора? Дык это нормально. Обычный режим внешнего клока.

[Dog Pawlowa]

Это немного не то. Контроллер CAN дал Вам просто поделенную частоту своего кварцевого генератора? Дык это нормально. Обычный режим внешнего клока.

Само то.
После сброса контроллер CAN делит частоту на делитель по умолчанию, и частота получается низкая. Делитель должен быть изменен, чтобы контроллер более-менее шевелился, и это делается через SPI без проблем. Но в этот самый момент разница в периоде двух соседних клоков получается намного больше 2%.

[Rst7]

Само то.

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

[galjoen]

Само то.
После сброса контроллер CAN делит частоту на делитель по умолчанию, и частота получается низкая. Делитель должен быть изменен, чтобы контроллер более-менее шевелился, и это делается через SPI без проблем. Но в этот самый момент разница в периоде двух соседних клоков получается намного больше 2%.

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

[МП41]

А я помню ещё на заре появления AVR было сказано, что за счёт внутреннего умножителя на 6 удалось достигнуть 1MIPS=1МГц, в отличии от 51-го ядра. Умножитель, я так понимаю, это ФАПЧ конечно же.

[rx3apf]

А я помню ещё на заре появления AVR было сказано, что за счёт внутреннего умножителя на 6 удалось достигнуть 1MIPS=1МГц, в отличии от 51-го ядра.

Вероятно, это эффект "ложной памяти". Такого - никогда и никто (производитель, в смысле - выдумки "популяризаторов" не в счет) не заявлял. С самого начала утверждалось:
----
The AVR pre-fetches an instruction during the previous instruction execution and then
executes in a single clock cycle. In other CISC- and RISC-like architectures, the external
oscillator clock is divided down (by as much as 12 times) to the traditional internal
execution cycle. The AVR enhanced RISC microcontrollers execute an instruction in
a single clock cycle and are the first true RISC machines in the 8-bit market.
----

[МП41]

Возможно. Это было где-то в сравнении пиков и АВР-ок.

Сообщение отредактировал МП41 - Mar 24 2009, 14:32

[Rst7]

что за счёт внутреннего умножителя на 6 удалось достигнуть 1MIPS=1МГц

Ага. А в ARM'е тоже надо умножать - ведь за такт никак не успеть И в MIPS. И много еще где