Приоритет прерываний, и прерывание прерываний Опции

[PhX]

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

[zltigo]

...как

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

[smac]

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

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

[zltigo]

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

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

Если интервалы между таймерными прерываниями достаточно большие...

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

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

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

[defunct]

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

вот и надо считать с учетом что их несколько.
Напр. 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.
И здесь все Ок.

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

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

[zltigo]

вот и надо считать с учетом что их несколько.

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

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

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