Вы сами себя запутали. Чел пишет, что выбрано "прерывание по совпадению и автоматическая очистка счетчика при условии сравнения. С предделителем 256 получаю частоту прерывания ровно 125 Гц (64000 тактов). И в прерывании делитель ставлю на 125"

Чтобы получить 125 Гц ему надо поставить счётчик на 31250/125=250. А вот дальше начинаются непонятки. Из приведенного фрагмента видно, где сбрасывается переменная times, но не видно, где она инкрементируется. То есть непонятно, на сколько делится 125-ти герцовое прерывание - на 125 или 126, чтобы инкрементировать секундный счетчик. На мой взгляд, данная неточность вкупе с неточностью кварца даёт искомую ошибку.

И не надо так шутить "с пистолетом у виска", вы ещё не на все вопросы по программатору ответили(:-).

Я сам себя не путал. Чел пишет, что Это наводит на мысли об использовании Output Compare Unit и OCR0B регистре. Следующим постом демонстрируется код, в котором используется прерывание, повторюсь еще раз ПО ПЕРЕПОЛНЕНИЮ счетчика ТС0. В теле прерывания видна переменная time, которая неизвестно где инкрементируется, но проверяется, и "автоматически" обнуляется Так что я не запутался, просто Вы, уважаемый, посты через строчку читаете



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

Вы хотите сказать, что при использовании Output Compare Unit не возникает флага переполнения?

Ну положим, уважаемый, вы сами сказали, что запутались, я вас за язык не тянул(:-). А посты я читаю как надо, не волнуйтесь за меня.

И не думал ехидничать, прошу прощения, если обидел. Хотел просто обратить внимание, что не следует шутить на тему смерти.

Я хочу сказать, что человек не использует Output Compare Unit, а использует переполнение счетчика ТС0, неужели это не понятно??? Таким образом у него получается частота 8.000.000 / 256 (прескалер) / 256 (переполняемый ТС0) = 122, .... Гц. Я сделал такой вывод, потому что человек привел код с прерыванием по переполнению.



А если бы он использовал OCR0A = 250 и использовал прерывание по совпадению, то у него бы получилось 8.000.000 / 256 (прескалер) / 250 (ТС0 == OCR0A?) = 125 Гц. Вот тут, пожалуйста, инкрементируй переменную time и проверяй ее на меньше 125



Точнее OCR0A = 249

Да откуда вы взяли, что он не использует Output Compare Unit? При его использовании установка флага переполнения счетчика ТС0 (и соответственно, возникновение прерывания по переполнению) возможна, например, когда биты WGM=001 или 101 (см. с. 79 документа 2543i).

Флаг TOVF устанавливается при достижении максимального значения в режиме CTC
Смотреть даташит таблица 40






Можно использовать любое прерывание из OCA / TOVF - результат будет одинаковым в режиме CTC.

Ну про такие извраты (извиняюсь) для получения одной секунды я вообще не думал. То что Вы привели относится к Fase Correct PWM mode - флаг переполнения возникает каждые 512 входных импульсов - интересно было бы увидеть Ваши мысли по тому, как парень в таком режиме счетчика считает 1 Гц...

Я не говорил, что флаг TOVF не установится вообще в режиме СТС, но это возможно если OCR1A = 0xFF.

Тогда не будет нужных 125 Гц, В режиме PWM Fase correct, так как период переполнений равен 512-и входным импульсам (256 - ++ и 256 --) тоже нет возможности получить 125 Гц. По этому я эти режимы и возможности не привел - для меня это было очевидно.

ИМХО парень просто ошибся в расчетах. Будем ждать, что он скажет...

Это происходит при любом значении OCR0A.
В CTC режиме TOVF устанавливается при TCNT == OCR0A
Посмотрите же даташит на t2313 наконец.
В CTC режиме события OCA и OVF происходят синхронно. Можете и на эмуляторе проверить заодно.


всяко может быть.

Да ни в жисть не поверю пока носом не ткнете - еще раз утверждаю флаг TOVF = 1, только если ТС0 = 0xFF!!!

Всем еще раз нужно заглянуть в datasheet на ATtiny2313.
На рисунке "Figure 31. CTC Mode, Timing Diagram" видно, когда "OCnx Interrupt Flag Set." Надписи "TOVn Interrupt Flag Set" вообще нет, так как прерывание по переполнению никогда не срабатывает.
В конце секции читаем:

MAX = 255
Если OCR0A < 255, счетчик никогда не досчитывает до 255.

Непонятно, каким образом прерывание вообще вызывается. Может, компилятор оптимизирует

В прикрепленном архиве проект avr-studio для эмуляции поведения TOVF.
Загрузите test.aps в Avr-Studio, в открышемся ASM файле должны быть расставлены точки останова на строки

rjmp TIM0_OVF ; Timer0 Overflow Handler
и
rjmp TIM0_COMPA ; Timer0 Compare A Handler

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

Откомпилируйте проект и запустите. Сработает первая точка останова (на строке COMPA), после этого идите по шагам, и внимательно проследите за TOVF таймера 0. Если облом следить - то просто запустите тест дальше - и вы попадете во вторую точку останова - прерывание по OVF.

В тесте установлен режим CTC, OCR0A установлен в 250.
TOVF устанавливается в 1 непосредственно в момент сброса TCNT в 0. (иначе и быть не может, т.к. раз сбросился - значит переполнился)

Вот вот, и я о том же. В PWM mode, такое будет, так как счетик в любом случае достигнет MAX, то бишь 0xFF (как и указано в даташите). В СТС режиме только если OCR0A = 0xFF.

Это опечатка в даташите. Там должно быть:

TOP = 255
BOTTOM = 0
MAX = максимально достижимое значение определяемое OCR0A

Oxo Это кто кроме Вас сказал? Во всех даташитах чтоль???

Тогда и в тексте описания ошибки, и во всем разделе "Таймеры" десятки ошибок. В ATmega8 datasheet все написано точно также.
Не может такого быть. MAX=255, TOP = OCR0A