Народ, вот такой вопрос. Будет ли нормально работать МК, если тактовая частота будет меняться в некоторых пределах, скажем, 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.
Чёта эти атмеловцы тут недогаваривают, однозначно