Можно ли добиться малого джиттера системного таймера, если есть прерывания с приоритетом выше сист. таймера Опции

[Дон Амброзио]

Мне требуется в обработчике системного таймера вести поллинг сигнала (потому что в MCU таймеров всего 2 (ATmega8515): один используется для ШИМ, а другой как сист.таймер).
Для этого требуется маленькая погрешность точек на временной оси взятия отсчётов сигнала.

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

А как вообще в операционках решают задачу когда прерывание с более высоким программным приоритетом обслуживания имеет низкий аппаратный приоритет. Как для него добиваются того, что даже при наличии прерываний с аппаратным приоритетом выше его приоритета LatencyTime было для него в допустимых пределах?

Сообщение отредактировал Дон Амброзио - Mar 6 2008, 07:04

[vshemm]

SSerge умолчал о самом главном: после проверки флага прерывания от таймера (т.е. самого приоритетного в рамках системы) в других обработчиках нужно разрешить вложенные прерывания. Иначе к джиттеру добавится "хвост" от более высокоприоритетного (аппаратно) прерывания
Только такой способ не сильно отличается от запрета всех нижлежащих перерываний и "разруливании" ситуации в одном обработчике (по критерию джиттера, конечно).

[Baser]

SSerge умолчал о самом главном: после проверки флага прерывания от таймера (т.е. самого приоритетного в рамках системы) в других обработчиках нужно разрешить вложенные прерывания. Иначе к джиттеру добавится "хвост" от более высокоприоритетного (аппаратно) прерывания

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

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

Зачем искусственно ограничивать возможности системы по скорости обработки прерываний? При малой нагрузке (частоте различных событий) это уменьшит время реакции до периода этого "главного" прерывания.

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

[vshemm]

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

Ну как не получим, ведь проверка запроса от таймера есть в начале каждого обработчика. Возникнет наше прерывание - отлично, если не наше - тут же проверим запрос. Т.о., мы избавимся от "Далее вызов этой функции натыкал во все другие длительные прерывания равномерно". Фактически, это означает проверку запроса каждые 50 тактов в данном случае.
Однако, обработчики будут выполняться при разрешенных вложенных прерываниях, и это нужно учитывать при их написании.