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

[=GM=]

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

[Rst7]

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

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

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

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

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

[galjoen]

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

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

[=GM=]

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

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

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

[galjoen]

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

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

[=GM=]

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

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

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

[fmdost]

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

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