ATmega timer2 в асинхронном режиме, что-то я слегка запутался... Опции

[rx3apf]

Долго воевал с потерей прерываний от переполнения TCNT2 (MEGA168), работающим от часового кварца в асинхронном режиме, пока не сообразил посмотреть эрраты. Да, при модификации регистров таймера в момент переполнения именно такая ситуация как раз и возможна (а я как раз энергично дергаю OCR2). Но какой же выход предлагает Atmel - проверять TCNT2 на FF перед любой модификацией регистров. Сделал. Стало еще хуже. Стал выяснять, почему. Получается странная картина - флаг TOV2 устанавливается через 1/32768 sec после момента перехода TCNT2 FF->00, и, если я терпеливо жду, когда TCNT2 выйдет из состояния FF, то как раз попадаю в момент, когда таймер стал равен 00, а TOV2 еще не установился. Пишу в OCR2 - и _гарантированно_ теряю прерывание переполнения ! Посмотрел последнюю версию даташита - они предлагают все тот же способ обхода проблемы, контролем на FF. Ну и что делать ? Ждать FF->00, а потом появления TOV2, и лишь потом трогать регистры ?

Это я не понимаю, как оно работает, или разработчики сами не понимают, как обойти столь изощренные грабли ?

[=GM=]

Ждать FF->00, а потом появления TOV2, и лишь потом трогать регистры? Это я не понимаю, как оно работает, или разработчики сами не понимают, как обойти столь изощренные грабли?

Всё понять невозможно(:-). Поскольку таймер асинхронный, запись значений в регистры TCNT2, OCR2x, TCCR2x идёт предварительно в соответствующие временные регистры и защёлкивается в регистрах через ДВА положительных фронта вашей асинхронной частоты, как я понимаю, тот же самый синхронизатор, который стоит на всех входных пинах. Для помощи был введён регистр асинхронного статуса ASSR. Проверяете бит3 (OCR2AUB) и вперёд. Или ждёте TOV2 в прерывании.

[rx3apf]

Всё понять невозможно(:-). Поскольку таймер асинхронный, запись значений в регистры TCNT2, OCR2x, TCCR2x идёт предварительно в соответствующие временные регистры и защёлкивается в регистрах через ДВА положительных фронта вашей асинхронной частоты, как я понимаю, тот же самый синхронизатор, который стоит на всех входных пинах. Для помощи был введён регистр асинхронного статуса ASSR. Проверяете бит3 (OCR2AUB) и вперёд. Или ждёте TOV2 в прерывании.

Статусный бит проверять бесполезно - он отслеживает состояние обновления _после_ записи. Ждать TOV2 тоже накладно - у меня прерывание каждые 250 mS. Короче, пока обошелся проверкой TCNT2 на FF и 00, если одно из них, то кручу цикл, пока таймер не выйдет из этих "запрещенных" вариантов. Меня смущает именно рекомендация Atmel проверять _только_ на FF, это прямой путь к усугублению проблемы...

[=GM=]

Статусный бит проверять бесполезно - он отслеживает состояние обновления _после_ записи. Ждать TOV2 тоже накладно - у меня прерывание каждые 250 mS. Короче, пока обошелся проверкой TCNT2 на FF и 00, если одно из них, то кручу цикл, пока таймер не выйдет из этих "запрещенных" вариантов. Меня смущает именно рекомендация Atmel проверять _только_ на FF, это прямой путь к усугублению проблемы...

Нашёлся ещё один вариант - обрабатывать прерывание по совпадению, не равному 0xFF, прерывания будут идти с тем же периодом, что и TOV2, но не будет потери прерывания и не надо будет беспокоиться о проверке на 0х00 или 0xFF.

[rx3apf]

Нашёлся ещё один вариант - обрабатывать прерывание по совпадению, не равному 0xFF, прерывания будут идти с тем же периодом, что и TOV2, но не будет потери прерывания и не надо будет беспокоиться о проверке на 0х00 или 0xFF.

А, в самом деле интересная мысль (да можно было бы и по совпадению на FF или на 00, все равно должно бы работать). Да, на M168 я мог бы сделать именно так (один из OCR2 свободен), но, к сожалению, аналогично надо решать и для M8, а там только один блок сравнения, и его-то и надо перепрограммировать по ходу работы. Так что у меня пока два варианта - проверять на FF и 00, и циклиться, либо проверять переход FF->00 и ждать TOV2. Второй по времени быстрее, но код развесистее и сложнее.