AVR, меняется время срабатывания прерывания

[Vitiril]

Прошу сообщество посмотреть простейшую программу:
#include ‹mega8535.h›
unsigned char Cnt;

// Timer 0 overflow interrupt service routine
interrupt [TIM0_OVF] void timer0_ovf_isr(void)
{
// TCNT0=0;
PORTD = Cnt;
}
...
void main(void)
{
...
PORTD=0x00;
DDRD=0x01;
// Timer/Counter 0 initialization
// Clock source: System Clock
// Clock value: 8000,000 kHz
// Mode: Normal top=FFh
// OC0 output: Disconnected
TCCR0=0x01;
TCNT0=0x00;
...
while (1)
{
// #asm("wdr");
if (PIND & 1) Cnt = 0; else Cnt = 1;
};
Осциллографом смотрим PORTD.0. Без операции TCNT0=0 в обработчике сигнал частотой 15617 Hz, с разрешенным TCNT0=0 сигнал на выходе частотой 15014 Hz. И вообще, изменение объема тела обработчика вызывает изменение частота сигнала на выходе. Всегда считал, что после вызова обработчика таймер продолжает тикать и сигнал на выходе должен иметь одну, установленную, частоту независимо от тела обработчика (в разумных пределах). В чем может быть проблема? Используется CVAVR.

[lsa]

Так проблемы нет. Что написали так и работает.
Происходит прерывание, внутри прерывания вы трогаете TCNT0, таймер считает заново и частота уменьшается.
Изменение объема тела обработчика вызывает опять же изменение TCNT0. Поставьте другие команды (не меняющие таймер) и ничего не изменится.

[Vitiril]

Уверяю Вас, что изменяется. Этот пример я привел как первое, что пришло в голову. У коллеги, который обнаружил это и попросил меня проверить это недоразуменье, операции с TCNT0 нет, а есть пара простых операций присваиванья значений (делал на atmega8, CVAVR).

[niXto]

К тому моменту, как процессор перейдет по вектору прерывания, тцнт успеет после обнуления насчитать еще десятки циклов, после чего ты его обнуляешь - т.к. проц НЕ МОЖЕТ мгновенно перейти на вектор прерывания, и в итоге получается что он кроме своего значения считает ещё и эти десятки = частота уменьшается. Все правильно...

[ForcePoint]

Этот пример я привел как первое, что пришло в голову.

Ваш пример так и должен работать. Можете привести реальный пример Вашего коллеги?
Как вариант - если разрешено более одного прерывания, то

interrupt [TIM0_OVF] void timer0_ovf_isr(void)

не будет вызван, если МК уже обрабатывает другое прерывание. Надо либо согласиться с джиттером, либо использовать вложенные прерывания (в менее важных обработчиках ставить в начале SEI).

[Boba_spb]

Чудес не бывает - как у маленьких детей.

С очисткой счетчика таймера Вы теряете 10 - 11 тактов процессора - это как раз и занимает время вхождения в прерывание, сохранение регистра в стеке, обнуление регистра и запись регистра в счетчик.

[Vitiril]

Благодарю ответивших. С задержкой по входу в обработчик согласен, но...
Привожу программу коллеги:

...
#define p_out PORTD.0
unsigned int main_count;
unsigned char ind_count;


// Timer 0 overflow interrupt service routine
interrupt [TIM0_OVF] void timer0_ovf_isr(void)
{
//main_count++;
main_count++;
if(main_count ›= p_off)
{
p_out = 0;
//p_out = p_out^1;
}
if(main_count ›= 800)
{
p_out = 1;
main_count = 1;
ind_count++;
if (ind_count == 3) ind_count = 0;
}
}

...
main
{
...
// Clock value: 16000,000 kHz
TCCR0=0x01;
TCNT0=0xAA;
...
}
В программе реализовано только прерывание таймера0, иных нет. В приведенном виде частота на PORTD.0 78,3210Hz. Раскомментариваем еще один main_count++; и получаем на выходе 78,1251Hz. Никаких переинициализаций TCNT0 нет.

[ForcePoint]

Если задержка в один период некритична, то можно поставить вывод в порт в самом начале обработчика и выводить значение, рассчитанное в предыдущем цикле.
Если критична:

1. Как-нибудь прикрутить режимы сравнения или ШИМ.
2. Переписывать обработчик на ассемблере с выравниванием времён исполнения всех веток.

[Vitiril]

Признаться сам по себе разбег времянки в данном контексте не так для меня важен. Получается, что использование кварцованного таймера как формирователя точных временных интервалов невозможно. Вот это для меня после нескольких лет использования Atmel`овских девайсов новость. Хотя вроде никогда не была нужна особая точность.

[Boba_spb]

все возможно, только надо понимать что Вы пишите .

Поспорим что p_off у вас четное число?