[s_gary 0]

Дык, достаточно сбросить CKDIV8 перед установкой RC 128 kHz?

Достаточно, конечно же, так и надо делать!

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

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

Думаю хотя бы один раз каждый наступил на эти грабли с фьюзами для тини от Атмела и частотой 128к.

 

Правда на каком-то форуме один механизатор штуки 3-4 тини13 "задвинул" таким образом и только потом пришел на форум сказать, что ему какие-то ТИНИ бракованные попались и где купить нормальные небракованные.

[adnega 10]

Думаю хотя бы один раз каждый наступил на эти грабли с фьюзами для тини от Атмела и частотой 128к.

Фьюзы - это вообще отдельный разговор. Без HW-программатора легко понаделать "кирпичиков".

Благо, я еще со времен ATtiny11 сделал себе HW-программатор и очень дотошно ставил и снимал галочки в PonyProg,

т.к. была возможна путаница с точностью до наоборот.

[asc2000 0]

Depending on CKSEL fuses, a valid clock must be present. The minimum low and high periods

for the serial clock (SCK) input are defined as follows:

Low: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz

High: > 2 CPU clock cycles for fck < 12 MHz, 3 CPU clock cycles for fck >= 12 MHz

Мне кажется, что Fck == Fcpu.

Fcpu получается путем деления выбранного источника тактового сигнала на соответствующий предделитель, который меняется в зависимости от CKDIV8.

Но ведь для fck >= 12 MHz единственный возможный коэффициент деления предделителя - это 1 (т.е. без деления частоты), т.к. даже для коэф-та 2 получается, что частота источника тактового сигнала >= 24 MHz, а это недопустимо для ATtiny13. Следовательно, fck - это частота непосредственно самого источника тактового сигнала, а не после предделителя.

 

В процессе программирования и в рабочем режиме МК тактируется от выбранного источника (структурная схема в разделе System Clock and Clock Options) и CKDIV8 влияет на коэффициент деления частоты (в соответствии с установкой).

 

Но, во-первых, из структурной схемы в разделе System Clock and Clock Options непосредственно не видно, что CKDIV8 влияет именно в режиме программирования.

Во-вторых, в разделе Serial Programming сказано, что на процесс SPI-программирования влияют установки фьюзов CKSEL1 и CKSEL2, но ничего не сказано о влиянии фьюза CKDIV8.

 

 

[adnega 10]

Но ведь для fck >= 12 MHz единственный возможный коэффициент деления предделителя - это 1 (т.е. без деления частоты), т.к. даже для коэф-та 2 получается, что частота источника тактового сигнала >= 24 MHz, а это недопустимо для ATtiny13. Следовательно, fck - это частота непосредственно самого источника тактового сигнала, а не после предделителя.

Ничего не понял, что вы пытаетесь сказать.

Подаем с генератора 20 МГц с предделителем /1, получаем необходимость минимум 3 тактов CPU в SCK для каждого уровня при программировании (т.е. 20/(3+3) => не более 3.333 МГц).

Устанавливаем предделитель /2, получаем необходимость минимум 2 тактов CPU в SCK для каждого уровня при программировании (т.е. (20/2)/(2+2) => не более 2.5 МГц).

 

Но, во-первых, из структурной схемы в разделе System Clock and Clock Options непосредственно не видно, что CKDIV8 влияет именно в режиме программирования.

Во-вторых, в разделе Serial Programming сказано, что на процесс SPI-программирования влияют установки фьюзов CKSEL1 и CKSEL2, но ничего не сказано о влиянии фьюза CKDIV8.

Вот если бы было сказано, что CKDIV8 не влияет в режиме программирования, и устанавливается принудительно предделитель /1, то это был бы факт.

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

[asc2000 0]

Вот если бы было сказано, что CKDIV8 не влияет в режиме программирования, и устанавливается принудительно предделитель /1, то это был бы факт.

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

Может быть и так.

 

Но напомню, что данная ветка форума начиналась с другого вопроса: почему программатором перестали читаться фьюзы и записанная программа?

Ведь я не менял CKDIV8, а только применил в своей программе коэффициент деления 256 установкой регистра CLKPR. Неужели эти установки сохраняются и в режиме программирования? В даташите я не нашел никакого объяснения по этому поводу.

 

 

[adnega 10]

Ведь я не менял CKDIV8, а только применил в своей программе коэффициент деления 256 установкой регистра CLKPR. Неужели эти установки сохраняются и в режиме программирования?

Если программа успеет записать CLKPR, то частота понизится и программировать на высокой частоте SCK не получится.

Если успеть подключиться программатором (а программа при этом останавливается?) до записи делителя /256, то программировать можно на высокой частоте SCK.

[asc2000 0]

Если программа успеет записать CLKPR, то частота понизится и программировать на высокой частоте SCK не получится.

Кажется, начинает проясняться. Как известно, SPI-программирование происходит при низком уровне на входе RESET. А в даташите сказано: "During reset, all I/O Registers are set to their initial values...". Т.к. CLKPR является одним из I/O Registers, то он также должен установиться в начальное значение. Я почему-то считал, что начальное значение - это 0, но получается, что это не всегда так. И вот тут опять непонятно: ведь CLKPR относится к энергозависимой памяти (SRAM), и при отключении питания его содержимое должно сбрасываться, и этот регистр должен устанавливаться в 0 ? Каким же образом в нем все же сохраняются его установки?

Изменено 7 января, 2016 пользователем asc2000

[rx3apf 0]

В имеющемся под рукой экземпляре даташита на tiny13 начальное состояние битов прескалера не указано, вместо этого идет ссылка на таблицу значений прескалера. На эту же таблицу ссылается и упоминание CKDIV8. Сложив 2 и 2, можно предположить, что при CKDIV8=0 прескалер будет делить на 8 сразу же после сброса и его действие может распространяться и на программирование тоже. Да, в даташитах от Atmel регулярно приходится "догадываться"...

[Nagisa 0]

Я записал новую программу, в которой применил коэф-т деления генератора на 256. Программа записалась и правильно работает, но контроллер перестал читаться и я больше не могу его перепрограммировать. Подскажите, что могло произойти и как избежать этого в дальнейшем?

из опыта, следует уделять особое внимание наличию блокировочной емкости по питанию МК

сам сталкивался со случайной прошивкой лишних фьюзов из-за помех.