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

А почему нет ?

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

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

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

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



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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

А я помню ещё на заре появления 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.
----

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

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