Есть три обработчика прерываний:
От Timer1
от INT0
и допустим
от Timer2
Прерывание от INT0 наиважнейшее не обработается вовремя расстрел (считает импульсы энкодера максимальная частота 250 КГц). Вопрос как сделать так, чтобы это прерывание имело наивысший приоритет и прерывало обработчики остальных прерываний?
Компилятор WinAVR.

Поскольку никакой аппаратной поддержки ни вложенности, ни приоритетов у AVR нет, то только руками - при входе в прерывания запретить индивидуально таймерные и затем поднять контроллеру флаг I автоматически сброшенный при входе в обработчик. Не забыть породелать обратную оперрацию при выходе. Это все лишние такты и критические секции, что для 250KHz-64такта не подарок.... Легко можете пролететь.

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

Также можно попытаться уменьшить латентность обработчиков таймерных прерываний. Если латентность каждого из них в отдельности будет меньше 64 тактов, то гарантированно ни один INT0 не потеряется. Вследствии того, что если будет два необработанных interrupt request'a выиграет INT0.

По-моему, в ваш ответ вкралась некоторая неточность, не сочтите за наглость. Сам подход, конечно единственно правильный, но у автора темы задача прерывать не внешнее INT0 прерывание, а наоборот таймерные, поэтому нужно при входе в таймерные прерывания разрешать прерывание от инт0 вскинуть флаг разрешения общих, а вот в обработчике инт0 ничего делать по идее не нужно. Конечно, при таком подходе есть вероятность "пролететь" таймерные прерывания, во время обработки инт0.

INT0 и так разрешено, а запретить нужно таймерные и прочие, кроме INT0, иначе они будут тоже прерывать текущее.



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



Нескольким подряд INT0 просто вообще хватит времени, если между ними вклинится 64 такта таймера. INT0 потеряется при обработке предыдущего INT0.

вот и надо считать с учетом что их несколько.
Напр. INT0 занимает 48 тактов на обработку (период - 64 такта) - 75% ресурса проца.
T1 - 100 тактов (период - 10K тактов)
T2 - 200 тактов. (период - 10K тактов)

считаем.
гарантированное время для обработчика T1 (при любых раскладах он получит столько времени до наступления следующего прерывания) - 10K * 0.25 - 200 = 2300 тактов, 2300 > 100 все Ок.
гарантированное время для обработчика T2 соответвенно:
10K * 0.25 - 100 = 2400 (> 200).

Не нравится одинаковый период, попробуем для разных:
INT0 - 48 тактов (75%).
T1 - 100 тактов (период - 10K тактов)
T2 - 200 тактов. (период - 1K тактов)

гарантированное время для обработки T1 = 10K * 0.25 - (10K/1K * 200) = 2500 - 2000 = 500 (> 100).
для T2 без изменений 2400.
И здесь все Ок.


хватит если как сказано выше не 64такта таймера, а гарантировано меньше 64-х (напр 63).

Так считайте. Два с некратными периодами и что там будет при прерывании одного другим.

Разумеется нет. Думайте, сколько времени остается обработчику INT0 после Ваших 63 тактов.

Да, Вы правы, меня бес попутал.

А вообще задача похоже достаточно серьезная, на С, наверное, нужно будет очень глубоко вникнуть в суть кода. Вопрос к автору темы - а нет ли возможности считать импульсы с помощью таймера-счетчика?

Как правило, таймерные приходят с определённой периодичностью. Периодичность вполне высчитывается. Если их период превышает означенный период (4мс), то достаточно просто разрешить прерывание в таймерных обработчиках. Возможность 3 вложенных - не проблема. Это лишь незначительно увеличит время реакции на прерывание. Хотя здесь надо учитывать объём контекста для этих прерываний (при написании на Си). Важно также чтобы не использовались совместные переменные в прерываниях. Также необходимо увеличить размер стека (что естественно)

Не совсем понятно. Лишь бы не пришли одинаковые прерывания. То есть необходимо чтобы суммарное время обработки всех прерываний было меньше (с запасом) чем период найменьшего из прерываний.

Есть ещё ограничения. Столкнулся недавно. Нельзя так обрабатывать те прерывания, флаг которых не сбрасывается автоматически при входе в прерывание. Либо надо их запрещать перед разрешением.
Например при обработке USART_UDRE.

так посчитал. что неустраивает в расчетах.
И откуда у таймера будет некратный период.


Очевидно - все оставшееся время. Таймер не сможет прервать INT0.
Самое главное не пропустить ни одного INT, - влететь в обработчик INT0 до того как произойдет следующий INT0. Все остальное фиолетово, при условии что обработка самого INT0 занимает тоже строго меньше 64 тактов.

В этом и проблема, ибо хотят обрабатывать прерывания с частотой в 250KHz тут уже каждый такт для AVR становится значительным.



Я что,не имею права запустить таймер, напимер, на 1000 и 10001 тик? Или любые другие нацело не деляющиеся...

Именно, но необходимое и достаточное условие для того чтобы не терять события частоты F это:

A ) обрабока события должна происходить строго быстрее 1/F.
B ) Время между возникновением события и входом в обработчик должно быть сторого меньше 1/F.

Вот от этого и плясать.
"A" никак не зависит от обработчиков других прерываний.
"B" зависит от обработчиков других прерываний и может быть достигнуто двумя путями -
1)разрешением прерываний внутри левых обработчиков
2)сокращением латентности обработчиков.

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


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

Нет. третьи сутки идут "расстрельные" прерывания каждое длится по 63 такта. Периодически приходят несколько таймерных по 63 такта. Вопрос, что будет, если
1. таймерные не прерываются.
2.Если таймерные прерываются, но естественно, для программной реализации вложенности и приоритетов требуются критические секции.
3. Что-то мне подсказывает что Автор поднял вопрос не уложив программу в несколько тактов

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


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


Да - много неизвеcтных в его задаче.
Нужно знать как минимум периоды T1, T2 и хотя бы приблизительное время обработки каждого из трех событий. Тогда можно советовать наверняка.

Поскольку Вы начали строить всевозможные предположения, то я специально в вопросе убрал INT0 ,
но Вы успели отцировать первоначальный copy-paste вариант Ж(.

Таких гарантий при нескольких источниках прерывания нет.