Первый вариант позволяет таки учесть время, прошедшее с момента возникновения прерывания до момента собственно его обработки. Если требуется формирование не единичного интервала, а периода, равномерно размазанного вокруг расчётного значения, то он предпочтительнее.

xemul, согласен, забыл про это

Не совсем так, т.к. при загрузке TMR0 сбрасывается прескалер.
Тогда уж логично сбрасывать не только прескалер, а и сам основной счетчик.
В этом случае мы как раз и получаем второй вариант.Ну, на самом деле это в принципе одно и то же (первый и второй вариант). Просто второй вариант действительно предзагрузка, а первый - предсуммирование или преддобавка, что звучит уж совсем коряво
Относительно "равномерно размазанного" интервала я не понял.
Если предзагрузку ставить вначале ППОП (до ветвлений и других участков ППОП с неопределенным временем исполнения),
то никакой "размазаности" не будет. Будет четкий период.

Рассмотрите случай с несколькими источниками прерываний, когда прерывание от таймера возникает после проверки его флага, но внутри ППОП.
Сброс прескейлера, в предположении, что он равномерно размазан на все состояния прескейлера, учитывается совершенно отдельно - типа "TMR0 += TMR0_PRESET + 1;" (или, ещё точнее "TMR0 += TMR0_PRESET + 0.5;" - т.е. 1 добавляется через раз).

Случай нескольких прерываний можно заменить, например, случаем, когда в основной программе есть куски с запретом прерываний.
Другими словами, мы говорим о случае, когда время реакции на прерывания непредсказуемо.
В этом случае надо смотреть на конкретный код программы. Если задержка реакции укладывается в несколько "тиков" таймера, тогда суммирование может нас спасти и обеспечить точность периода прерываний в пределах одного тика таймера.
А если задержка может быть большая, то вообще теряется смысл предустановки.
Можно рассмотреть и другой случай. Пусть задержка лежит в районе одного тика таймера плюс-минус несколько тактов Fosc/4.
В этом случае прибавление константы дает нам "дрожание" периода прерываний примерно на величину одного тика таймера.
А если мы выполняем загрузку таймера константой, то "дрожание" периода имеет величину всего лишь нескольких тактов Fosc/4.
Так что бывают случаи, когда загрузка лучше суммирования

Я могу обосновать чиста математически, что загрузка в любом случае будет не лучше суммирования в смысле получения минимальной средней (или средней квадратичной - без разницы) ошибки формирования некоторого периода на любом числе периодов.
Случай, когда загрузка будет равна по ошибке суммированию, вообще один - прерывания только от таймера с минимальным прескейлером, никаких критических секций в коде.
Из очевидных минусов загрузки - собственно загружаемую константу придётся подрихтовать ручками, чтобы учесть задержку от возникновения прерывания до момента загрузки, или вставлять каким-либо образом этот учёт в считалку препроцессора. При суммировании оно учитывается само, и остаётся только решить, компенсировать ли сброс прескейлера или и так сойдёт.

Спасибо за гору инфы! Еще бы переварить...
Добавил квалификатор volatile а всем переменным, используемым в ППОП. От предзагрузки таймера временно отказался, пока не разберусь, что происходит. Пока мне точность не нужна.
Никак не докопаюсь, для чего нужен
ППОП и так вызывается при появлении прерывания по переполнению TMR0.
Также не пойму, как в некоторых случаях работает оператор while. В книге по микроС сказано:

У Кернигана и Ритчи иная точка зрения:

И где истина?

Сообщение отредактировал loghir - May 30 2011, 07:33

Интересна не столько средняя ошибка, сколько ее дисперсия. Она определяет "дрожание" периода прерываний.
Я выше приводил пример, когда время задержки между событием, вызывающим прерывание и моментом загрузки гуляет около одного
тика таймера.(тик таймера = период срабатывания прескалера). Будем считать, что идеальным вариантом для нас является суммирование прескалера, когда задержка равна точно одному тику. Этот лишний тик мы учтем в прибавляемой константе. Это будет соответствовать нулевой ошибке.
Если время задержки в какой-то момент оказалось чуть-чуть меньше тика таймера,
то ошибка при суммирование таймера будет равна почти одному тику из-за обнуления прескалера, который к этому моменту накопил почти целый тик.
Если задержка чуть-чуть больше одного тика, то при суммировании будет ошибка небольшая. Короче говоря, ошибка при суммировании будет определяться состоянием прескалера на момент суммировния. В среднем это примерно половина тика.
В случае загрузки константы в моем примере дрожание периода определяется только интервалом времени, в котором гуляет задержка.
Это интервал между "чуть-чуть меньше тика" и "чуть-чуть больше тика".
Разница между этими моментами времени может быть существенно меньше времени тика таймера (и даже его половины).
И следовательно, дисперсия периода будет небольшой. Чиста математически



Флаг запроса взводится автоматически при возникновении события, могущего вызвать прерывание.
А сбрасывать его должен сам программер в ППОП.
Сложность в том, что вы попадаете в одно и то же ППОП при срабатывнии прерываний от нескольких разных источников.
Вы должны определить, какой источник вас "позвал" в ППОП. Это делается опросом флагов запроса прерывания
(по-умному это называется "полинг прерываний".)
Если у вас разрешен только один источник прерываний, то эта проверка не нужна.

Истина в вине В смысле - оба источника правы. Т.к. "Ложь" кодируется нулем, а все остальное - "Правда"!

Дисперсия == (средняя квадратичная ошибка)^2.

Занятное определение, ну да ладно.
Мне это было интересно во времена, когда у пиков система прерываний отсутствовала как класс, а строить какие-то диспетчеры задач и формировать интервалы всё равно приходилось. Повозил немного карандашом, пришёл к выводу... С тех пор математика (точнее, арифметика) работы таймеров не изменилась. Но у каждого кулика своё болото.


Он нужен только переменным, _модифицируемым_ в прерываниях.

Не встречал задач, где предзагрузка таймера в комбинации с прескалером была бы хорошим решением. Без прескалера - это я понимаю.

Ну, это если "чиста математически".
Квадратичная ошибка, да еще и в квадрате - это сильно!
А если посмореть в букваре (можно в Википедии), то можно убедиться, что
Дисперсия ошибки == средний квадрат отклонения от средней ошибки.
Чувствуете разницу?

Вот что получилось:



Вот только не срабатывает! Как был "0" на индикаторе, так и остался.
Вариант

не изменяет скорость счета при изменении tmp100.
Попытка написать

после main() вызывает ощибку при компиляции.

Сообщение отредактировал loghir - May 30 2011, 14:33

Это что такое? Бесконечный цикл?
У вас проблемы не с микроконтроллером или с прерываниями.
У вас проблемы с элементарным программированием.

офигенное условие

Я же на прошлой странице привел фактически готовое решение, зачем столько хрени пихать в обработчик прерываний?

Коллеги!

Уважаемый loghir не хочет сам ничего делать (читать, изучать, советы слушать). Поэтому, не поддавайтесь на его стиль вытягивания не мытьем, так катаньем, готового результата и лучше всего, просто перестаньте реагировать на его вопросы.