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

Таймер действительно подсчитает столько импульсов, сколько ему задали, но на нем часики не заканчиваются. Ошибка будет накапливаться в последующих счетчиках.

О какой ошибке вы говорите!? Таймер тикает со своей скоростью выдавая сигналы на прерывание. Частота часового кварца точно делиться для получения секундных интервалов. Главное, чтобы прерывание успело доработать до следующего сигнала на прерывание. Ну будут цифры на табло обновляться позже соответствующего события таймера на доли секунды, ну и что? Время наступления следующего прерывания от этого не измениться.
Ошибка по таймеру может накапливаться если нет возможности средствами МК точно поделить исходную частоту для получения секундных интервалов (целых или в равных долях, не важно).
Коррекцию самого кварца я не брал в расчёт.

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

Да хоть дважды асинхронный! Пока заканчивается выполнение текущей команды, пока осуществляется переход на прерывание и т.д., таймер продолжает считать! Таймер из прерывания перезапускать не надо! Даже если не CTC режим, то можно легко успеть поставить следующее значение в регистр сравнения. А так как речь идёт о часовом кварце, то и это не требуется - нужно прерывание по переполнению. Откуда погрешность?

Если A и B это моменты переполнения таймера (момент установки соответствующего флага прерывания), а С и D, соответственно, моменты входа и выхода из прерывания, то длительность промежутка AB не зависит от длительности промежутков AC и CD. Ситуацию, когда AD >= AB не рассматриваем. О каком дрожании (джиттере) и компенсации чего вы говорите? Речь о часах, а не о системе с детерминированной реакцией в реальном времени.

Как уже ранее говорилось, часики - это не только секунд-генератор.
Кажущийся незначительным джиттер реакции на прерывание по основному таймеру будет влиять на длительность интервала минутного и далее счетчиков - ведь аппаратный счет только максимум - секунда, а допуск на +/-1 команду при 32786 весьма внушителен, по сравнению с тем же допуском при 8МГц
0,000030517578125*2=0,00006103515625
или
0,000000125*2=0,00000025
В то же время на индикацию (и к исполнению) принимаются как раз данные этих счетчиков - минуты, часы и десятки часов. В то же время, чем больший интервал времени отсчитыавет аппаратный счетчик, тем больше погрешностью по его прерываниям можно пренебречь. При этом, чем меньше время выполнения команд (и, соответственно, реакции на прерывание) по отношению к аппаратно заданному интервалу, тем меньше результирующая погрешность.
Или режим:
тактовый внешний кварц 8МГц без предделителя (0,000000125S/команду)
при режиме таймера СTC, предделитель 256 и OCR1AH:OCR1AL=31250
будет давать большую погрешность 1 секундного интервала, чем вышепредлагавшееся тактирование от 32786?
Это при том, что интервал между прерываниями потенциально содержит 8000000 команд против 32768... да и относительная погрешность, вносимая реакцией на прерывание несоизмеримо меньше...
Такая реализация удобна лишь при условии применения интеллектуального контроллера ЖКИ, при светодиодном индикаторе и наличии клавиатуры (динамическая индикация) там несколько другой вариант удобнее будет.
Просто по опыту работы с менее "приспособленными" таймерами mcs51 (пока не было Т/С2 там автоперезагрузка допускалась только при 8-разрядном варианте и далее каскадированте второго аппаратного счетчика и программных счетных регистров) все эти "мелочи" даавно перепроверены...

BOB51
По моему Kavka популярно всё объяснил. Нет никакой разницы где находятся точки C и D, главное чтоб они были между A и B.
Кнопки, дин индикацияю и т.д. обычно не привязывают к отсчету времени, но даже если и привязали, то обрабатывайте их после точки D, когда уже состояние всех узлов стабильно.

BOB51, всё что вы написали имеет смысл, если по прерыванию надо запустить таймер по новой или "дёрнуть" сигнальчик строго по времени прерывания (тогда вам в начало вот этой темы). Но этого не требуется (тема про Atmel ATtiny2313). Или вы таки про другую архитектуру МК говорите. Никто не спорит, что ваши выкладки имеют место быть. Но на точность часов они влиять будут только если счёт реализовать полностью программно. Но в данном случае такие заморочки просто не нужны. Ещё раз повторюсь - таймер после генерирования события на прерывание продолжает считать! Это самое главное! Без разницы, в какой момент времени обновятся промежуточные счётчики в ОЗУ или регистрах и когда обновиться картинка на индикаторе. Главное, чтобы эти операции успели завершиться до следующего прерывания, а сами прерывания шли с фиксированной скоростью! Что и будет происходить, так как таймер не останавливается и, даже, не перепрограммируется/перенастраивается.

Вариант с делением 8МГц на 256 даёт целый результат, как вы и написали, 31250. Соответственно, погрешность будет только от кварца.
Более "мелкое" деление интервала может быть удобным для плавной коррекции хода или для сервисных функций (опрос кнопок, дин. индикация). Но если подобрать деление на цело, то опять таки, погрешность будет только от генератора.
Пусть те же 8МГц и хочется динамическую индикацию около 100Гц.
8000000/256=31250 отсчётов на секунду
А вот тут 31250 хорошо делиться, например, на 125, получается 250.
8000000 / 256(делитель таймера) = 31250 / 250(Output Compare Register, CTC mode) = 125 Гц - частота следования прерываний
Всё делиться на цело.

Котятки, не к тому интервалу прицарапались!
Поглядите вот на это:

BOB51, такое не возможно при тактировании таймера от системного тактового сигнала. Особенно так как вы нарисовали, со сдвигом и накоплением погрешности. Сдвиг момента установки флага прерывания от системного такта будет фиксированным, примерно равным времени распространения сигнала через делитель, и сдвиг будет, думаю, много меньше одного системного такта. Так как срабатывание делителя происходит, например, по нарастающему фронту системного сигнала (по одному_из/любому из фронтов). Картинка была бы правдоподобнее если бы вы нарисовали длительность команд пропорционально тактам и что событие на прерывание может возникнуть во время выполнения команды в момент близкий к фронту системного такта.
Скажите ещё, что количество команд между моментами прерывания должно быть одинаковым, чтобы не было погрешности.

Подобная картина возможна только при асинхронном режиме, когда частоты системного и дополнительно генератора отличаются не кратно. Да достаточно, чтобы они просто не совпадали.
Да и в таком случае событие на прерывание будет всегда выставляться +-1 период системного такта. Т.е. каждое отдельное событие на прерывание будет установлено с погрешностью в +-1 период системного такта относительно фронта реального сигнала. Но в среднем, время между прерываниями будет равно периоду реального сигнала.

В любом случае погрешность будет обусловлена только генератором.

Программа (команды) идут сами по себе, таймер сам по себе, а реакция на прерывание - "ни одна команда не может быть выполнена до завершения текущей"... даже ежли у аврок в среднем команда равна такту, есть еще конвеер предвыброки с нарушением очереди команд при прерываниях/условных переходах...
ИЗ вредности попробуй оба варианта тактирования при одинаковой программе обслуживания дисплейного индикатора - гда большее отклонение хотя-бы за неделю выползет.
А вот насчет того, скокмо команд между соседними прерываниями - в принципе безразлично, хош до полного останова... играет роль интервал от окончания аппаратного счета до фактической отработки программы начала прерывания, а там величина непредсказуемая и чем длиннее такты основного генератора, тем большая (от 0 до полной длительности 1 такта/команды при каждом вызове прерывания).

Ну вот, вы теперь сами пишете то, что я писал несколькими сообщениями ранее.
Но это не влияет на время между моментами установки флага прерывания от таймера. И всё равно какая задержка реакции будет...уже писал об этом.Вы про вариант с одним и двумя генераторами? Без разницы. Точность будет зависеть от точности генератора по которому у отсчитывается время. Как уже тут раньше упоминалось, часовые кварцы чаще встречаются с большей точностью (меньшим ppm), чем обычные (на мегагерцы). Соответственно собрав часы с "опорой" на часовом кварце можно с больше вероятностью получить большую точность. А если ещё грамотно конденсаторы подобрать/подрегулировать, как это было в отечественных часовых наборах на 176 серии...

BOB51, даже если забыть про программу, и рассмотреть просто работу таймера с идеальным кварцевым резонатором. Если он досчитывает до 32768 ровно раз в секунду и сразу же сбрасывается в 0 сам по себе, то откуда может появиться расхождение в периоде переполнения таймера?

Именно так - если забыть про программу (т.е. если вся система аппаратная). В отличии от аппаратной схемотехники будет иметь место разница во времени между установкой флага и началом исполнения программного кода прерывания (зависит от соответствующей начинки МК). Так что расхождение будет не в сработках таймера, а в последующей обработке полученных по прерыванияю интервалов (рисунок выложен ранее). Тот же минутный счетчик будет уже иметь отличие в 60 таких ошибок на каждую минуту в отличии от аппаратного счетчика подсчета секунд в минуте. Да и упаси боже от 4-х байтовых (двухсловных) команд в коде программы, на который могут попадать прерывания (это относительно АVR и других МК с фиксированной длиной команды).

Интересно, почему тогда опорные генераторы частотомеров не делаются массово на кварцах 32768?

Я говорю о точности системы в целом, в конечном итоге, в пределе. А она, точность, будет зависеть от опорного генератора.
Вы говорите о реакции МК на событие. Я и не спорю о наличии задержки при этой реакции (об этом я тоже писал в предыдущих сообщениях). Но наличие задержки при входе в обработчик прерывания на точность хода кварцевого генератора не влияет. Так же она не влияет на работу делителя и счётчика таймера.
Возможно вы так заковыристо про компенсацию хода пытаетесь донести. Но это совсем другое!

Я может немного не так вас понял, но вот, по-моему картинка иллюстрирует, что пока не будет в конец пропущено прерывание, показания часов никогда не отстанут более чем на 1 сек (при условии идеального кварца)

Спойлер

Аппаратный генератор, предделитель счетчика и таймер всегда генерируют одинаковый интервал, значение которого поддается коррекции путем изменения константы досчета.
Речь идет об ошибке, накапливаемой последующими счетчиками, для которых уже чистого секунд (маркер) интервала не будет из-за задержек, вносимых той самой реакцией на прерывание ( в примитиве см.мою "графку").
По той же причине некорректируемая погрешность (непредсказуемое значение задержки) тем больше, чем больше длительность исполнения команды. В таком случае тактирование системного генератора МК от более низкочастотного кварца вызывает более длительную реакцию на прерывание и, как следствие, более высокую погрешность счета не зависящую от точности аппаратного формирователя.
Да и точность кварцевого резонатора относительно нашей задачи...
формирование временного интервала производится импульсами определенной длительности
(подсчет не частоты, а длительности)
к примеру
кварц 32768 с погрешностью 0,5%дает интервал
0,000030517+\-0,000000152 секунды
а в то же время кварц 8МГц с 10%будет давать интервал
0,000000125+\-0,000000012 секунды
вот и получается, что тактирование базового генератора МК, если он одновременно и источник тактовой последовательности тайм-маркера более низкочастотным кварцем вызовет большую (по отношении к тактированию той же системы более высокочастотным кварцем) погрешность результата.
Именно это одна из причин применения в МК системах специальных независимых генераторов в случае применения кварца 32768 для систем со встроенным RTC.

Что-то я и так и эдак, но никак не могу понять что вы призываете компенсировать?
Ход часов относительно не идеального кварца? Как я уже говорил, это отдельная задача.
Вы считаете, что надо компенсировать задержки обозначенные синим?

blackx, я уж на вашей картинке. Надеюсь не возражаете.

НЕ компенсировать, а снизить, по возможности, их влияние и величину.

Зачем?