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

[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 тактов.

[defunct]

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

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

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

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

[zltigo]

...при условии что обработка самого INT0 занимает тоже строго меньше 64 тактов.

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

[defunct]

Нет. третьи сутки идут прерывания INT0 каждое длится по 63 такта. Периодически приходят несколько таймерных по 63 такта. Вопрос, что будет, если
1. таймерные не прерываются.

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

2.Если таймерные прерываются, но естественно, для программной реализации вложенности и приоритетов требуются критические секции.

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

3. Что-то мне подсказывает что Автор поднял вопрос не уложив программу в несколько тактов

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

[zltigo]

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

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

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

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

[defunct]

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

не суть важно, по условию задачи нам нужно не пропустить ни одного INT0. О всех остальных автор умолчал ;> Преполагаем что они не важны и их пропускать можно.

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

Заблуждение. И Вы сами это прекрасно понимаете, но не хотите сдаваться
Гарантии достигаются за счет опять же двух составляющих:
- минимальный период;
- макс время обработки
каждого прерывания.

Если время обработки == 0, гарантия 100%.
Если период стремится к бесконечности - гарантия 100%.

ну а для всех остальных случаев гарантии оцениваются/считаются.