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

[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.

[SasaVitebsk]

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

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

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

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

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

[zltigo]

Это лишь незначительно увеличит время реакции на прерывание.

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

И откуда у таймера будет некратный период.

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

[defunct]

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

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

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

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

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

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

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