ATmega16A: некорректно работает ШИМ

[KaCD]

Проблема вскрывается при "шагании" по коду в дебаггере (используется AVRStudio 4)
При настройке Таймера1(16-ти битный), я первоначально задаю значения в регистрах OCR1AH/L и OCR1BH/L, потом произвожу настройку Таймера1 на нужный мне режим работы
Трабл таков: если шагать по коду, то после строчек настройки регистров TCCR1A/B, старшие байты регистров OCR1A/B почему-то самопроизвольно меняются на совсем другие значения. Младшие байты не меняются.
Почему так происходит понять ни как не могу.
Хотя, если ткнуть осциллографом в ногу, куда выводится ШИМ, то там он будет иметь правильную форму, заданную регистрами OCR1A/B (правильность проверял также по получаемому периоду меандра)
Чтобы убедится, что это не глюк программы состряпал прерывание, в котором, по нажатию кнопки, сначала данные с регистров OCR1AH/L и OCR1BH/L копируются во временные регистры, а потом сразу же обратный процесс - из временных регистров в регистры сравнения.
Тут-то бага и вскрывается, т.к. старшие байты самопроизвольно поменялить так, что предел счёта стал меньше сравниваемого значения, ни о каком ШИМ речи не идёт (что осциллограф и подтверждает).

Посему и вопрос к светилам: в чём моя ошибка и как сделать так, чтобы старшие байты регистров сравнения не менялись?

[GP1]

Код: Выделить всё

t0_comp:

sbic pinD,1				
rjmp exit
in temp1,OCR1BH
in temp2,OCR1BL

out OCR1BL,temp2
out OCR1BH,temp1

exit:

согласно ДШ при записи первым пишется ст.байт, затем мл.
при чтении - сначало читается мл.байт, затем ст.байт
а у тебя все наоборот

а при инициализации все правильно:
сначала ст. потом мл.

[KaCD]

Замечание верное, но сути дела не меняет - всё равно старшие байты меняются и поэтому, в прерывании t0_comp, во временные регистры записываются неверные значения

[zero648]

Нужно в обработчике прерываний сохранять регистры и флаги в стеке, а при выходе восстанавливать, а иначе концов не найдешь.

[Engineer_Keen]

Нужно в обработчике прерываний сохранять регистры и флаги в стеке, а при выходе восстанавливать, а иначе концов не найдешь.

По хорошему да, но тут вся программа - инициализация и пара обработчиков прерывания, так что это не влияет.
Это явный глюк симулятора студии, поиграйтесь во время пошаговой отладки с битами WGM10-WGM13 и OCR и сравните результат с таблицей в даташите. Создается впечатление что WGM13 и 12 вообще не влияют на режим, остаются 8,9 и 10 битные режимы, в которых старшие 7-9 бит регистров сравнения просто обнуляются. Кстати в протеусе этого не происходит, в железе проверить не могу, 16я мега осталась на даче...

[BOB51]

сколько раз уже эти "грабли" повторяются...!
Читайте описание ограничений в работе дебаггера AVRstudio!!!

[KaCD]

Создается впечатление что WGM13 и 12 вообще не влияют на режим, остаются 8,9 и 10 битные режимы, в которых старшие 7-9 бит регистров сравнения просто обнуляются.

Согласен, действительно похоже на это, но, правда, отчего же?

Кстати в протеусе этого не происходит, в железе проверить не могу, 16я мега осталась на даче...

Чего именно не происходит в протеусе?

[Engineer_Keen]

Согласен, действительно похоже на это, но, правда, отчего же?

Написали уже - глюк симулятора, смиритесь с этим

Чего именно не происходит в протеусе?

Не обнуляются старшие биты в OCR. Хотя они там не обнуляются если и действительно 8-10 битные режимы ставить... Как должно быть на самом деле не знаю, никогда такие режимы (менее 16 бит для 16 разрядного таймера) не использовал.

[KaCD]

Согласен, действительно похоже на это, но, правда, отчего же?

Написали уже - глюк симулятора, смиритесь с этим

Пичаль... видимо придётся попробовать другой софт или другую версию того же АВРСтудио...

[BOB51]

у аврчатых симуляторов (и у симуляторов в большинстве) отлично проработано только "ядро", а чего касательно всяческой периферии и особенно "сложных" режимов - всегда будут различной степени ограничения...