Прерывание таймера Attiny не делает прерывание каждые 1000 мс

Я вижу три проблемы с этим подходом.

Во-первых, вы используете некалиброванное время очень низкого качества. источник. Частота внутреннего RC-генератора хороша с точностью до всего несколько процентов. Он также очень нестабилен и сильно зависит от температура. Использование внешнего керамического генератора на 16 МГц должно дать вам частоту, которая не хуже, чем 0,5% от, с типичным ошибка около 0,1%. Однако он все еще несколько нестабилен. Если вы вместо этого используете кварцевый осциллятор, то вы можете ожидать ошибку около десяти раз меньше (в пределах 100 ppm), и очень хорошая стабильность. В зависимости от ваших требований к качеству, 100 частей на миллион может быть недостаточно. достаточно хорошо, и в этом случае у вас все еще есть возможность измерить скорость дрейфа и откалибруйте ее (см. ниже).

Вторая проблема, которая уже поднималась 6v6g, заключается в том, что ваш таймер считает от нуля до 122 включительно, что дает период 123 такта таймера. Посмотрите на временные диаграммы в техпаспорт, если вам нужно убедить себя в этом. Если вы хотите период из 122, вы должны установить OCR0A на 121.

Третья проблема заключается в том, что вы сбрасываете таймер с помощью ISR. Этот может работать в этой программе, но это очень хрупкий подход, который стоит избегая. Проблема в том, что все, что делает микроконтроллер, занимает время, и ваш ISR может даже быть задержан другим прерыванием. Если таймер увеличивается после поднятия флага прерывания, но до того, как вы сбросьте его, вам не хватает одного счета. Если вы хотите иметь непрерывный шкале времени, никогда не сбрасывайте таймер. Вы можете:

• дайте ему работать непрерывно, без помех (и выполните OCR0A += 122 в течение ISR),

• или перезагрузите его, используя соответствующую генерацию сигнала режим (CTC или быстрый PWM).

Наконец, вот трюк, который вы можете использовать для калибровки секундомера. Вместо подсчета прерываний до тех пор, пока счетчик не достигнет 8 (что предполагает период прерывания ровно 1/8 с), увеличить a счетчик наносекунд внутри ISR и считать одну секунду, как только у вас есть один миллиард наносекунд:

const uint32_t nanoseconds_per_interrupt = 124928000;

ISR(TIMER0_COMPA_vect) {
    static uint32_t nanoseconds;
    nanoseconds += nanoseconds_per_interrupt;
    if (nanoseconds >= 1000000) {
        nanoseconds -= 1000000;
        seconds++;
        // затем обновить минуты, часы... если необходимо
    }
}

Это будет увеличивать секунды каждые восемь прерываний... время. Однако время от времени потребуется девять прерываний. Этот добавляет немного джиттера, но предотвращает ошибки синхронизации накапливаются и заставляют часы дрейфовать. Если дрожание видно, вы можно уменьшить, сократив период прерывания.

Значение 124928000, которое я написал выше, предполагает, что ISR вызывается каждый раз. 122×1024 цикла тактовой частоты 1 МГц. Вы можете изменить его, чтобы он соответствовал другую тактовую частоту или другую настройку OCR0A. Хитрость заключается в следующем: как только вы измерите скорость дрейфа секундомера, вы сможете настроить это число, чтобы удалить этот дрейф. Например, если вы измеряете секундомер и обнаружите, что он работает на 0,04% медленнее, тогда вы увеличиваете это число на 0,04% (что дало бы 124977971), и дрейф исчез.

ОБНОВЛЕНИЕ: в комментарии 6v6gt указал на четвертую проблему в вашем коде, что, вероятно, является самой большой проблемой. Ваша логика подсчета прерываний это:

if (intr_count == 8) {
    intr_count = 0;
} else {
    intr_count++;
}

Это счет от 0 до 8 включительно и цикл с периодом 9 прерываний. Более безопасная идиома для цикла с периодом 8 будет:

if (++intr_count >= 8) {
    intr_count = 0;
}

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