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

[vshemm]

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

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

[Baser]

Вторая фраза противоречит первой: получается из Ваших слов в AVR у прерываний приоритета нет, а вроде как бы и есть

Противоречия нет: уровень прерываний только один, но внутри этого уровня ессно есть приоритет различных прерываний.

И как же Вы уменьшали джиттер, используя вложенные прерывания? Наверное глобально разрешая как можно быстрей прерывания в обработчиках прерываний?

Именно так, как рекомендовал SSerge:
НаписАл функцию, которая дублирует мое самое высокоприоритетное прерывание. В ней проверяется наличие флага этого прерывания и после работы функции флаг сбрасывается. Далее вызов этой функции натыкал во все другие длительные прерывания равномерно, по времени обработки, исходя из необходимого максимального джиттера.

Вариант, несомненно, достаточно кривой, но он работает. Такой прием уже применял дважды, когда быстродействия и таймеров не хватало - проблем не заметил, все ОК

[vshemm]

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

[Baser]

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

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

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

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

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

[vshemm]

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

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

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

Спасибо всем ответившим.

Решил остановиться на таком варианте:

При наступлении любого прерывания всю обработку успевать делать в ISR за 120T {где T-период тактовой частоты процессора} при глобальном запрете прерываний {т.е. ISR не может быть прервана ничем}. В эпилоге же каждого обработчика проверять флаг запроса на прерывание от системного таймера.

Если флаг установлен, "вручную" его сбрасывать и НЕ РАЗРЕШАЯ ГЛОБАЛЬНО ПРЕРЫВАНИЯ переходить {командой RJMP} сразу в ISR системного таймера.

Если же флаг сброшен просто возвращаться в прерванный поток по команде RETI.

Да.. Ещё выделил регистр для флагов запросов на DPC. Т.е. если ISR всё же не успевает сделать всю работу за 120T, то она может {при желании} посигналить об этом установив соответсвующий флажок в этом регистре. А в эпилоге ISR системного таймера проверять этот регистр и если он не ноль отдавать управление диспетчеру DPC, который вызовет DPC уже в порядке мной установленного приоритета.

Этот же флаг будет использован ISR при наступлении следующего прерывания: в прологе каждая ISR будет проверять свой флаг в регистре запросов на DPC. И если он установлен, т.е. DPC этого прерывания ещё не успела отработать, а уже наступило новое прерывание - значит это CRASH.


С вложенными прерываниями не стал возиться потому что там возникает многа гимора. В частности, например, с переключениями стеков

Сообщение отредактировал Дон Амброзио - Mar 10 2008, 11:02

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

И ещё одно отступление сделал от "классической" схемы построения вытесняющих RTOS.

Везде аватары пишуть, что ISR может "сразу же" иницировать смену текущего running-потока если ISR обнаружила, что "созрел" поток с более высоким приоритетом, чем у текщего running-потока.

Я не стал это делать "сразу же".

Объясню почему...

Смена running-потока у меня занимает порядка 350T (это в наихудшем случае, тут всё зависит что за потоки меняются: мининити или главные нити процессов, поток со статическим или с динамическим приоритетом и т.п.).

А размер тика системного таймера у меня получился 1800T.

Рассмотрим ситуацию когда происходят друг за другом 4 прерывания и каждое последующее прерывание приводит к тому, что переходит в состояние Ready поток с более высоким приоритетом..

Вот и представьте теперь..

Произошло прерывание 1. Мы переключились на поток Thread1 и потратили 350Т.

Произошло прерывание 2. Thread1 не успев отработать даже микросекунду была прервана прерыванием 2. Переключились на поток Thread2 и ещё потратили 350Т.

Произошло прерывание 3. Thread2 не успев отработать даже микросекунду была прервана прерыванием 3. Переключились на поток Thread3 и ещё потратили 350Т.


Произошло прерывание 4. Thread3 не успев отработать даже микросекунду была прервана прерыванием 4. Переключились на поток Thread4 и ещё потратили 350Т.

Произошло прерывание системного таймера. Thread4 не успев отработать даже микросекунду была прервана прерыванием системного таймера.

В iSR системного таймера выясняем, что перешёл в состояние ready поток Thread5. На него и переключаемся в конце концов.



Вопрос: и какой смысл было тратить 1400Т процессорного времени если Thread1,..., Thread4 не отработали ни одной команды?


Поэтому я решаю вопрос о смене текущей running-нити только в эпилоге ISR системного таймера. Но для того чтобы реактивность системы не пострадал делаю размер системного тика достаточно маленьким. Всего лишь 1800T

Сообщение отредактировал Дон Амброзио - Mar 10 2008, 13:03

[vshemm]

При "классической" схеме подразумевается, что соотношение времени переключения тредов намного меньше (на порядки) периода системного тика. Поэтому, для уменьшения latency переключение делается при выходе из прерываний и других "интересных" мест. А уменьшение периода системного тика неоправданно из-за получаемого высокого оверхеда.
Кстати, сейчас широко получили распространение так называемые "tickless" системы, где таймер генерирует прерывание не с заранее данным периодом, а "когда нужно" Конечно, никто "полезную" работу (вычислительную) при таком подходе в обработчике таймера не делает.

Имхо, применять данные механизмы и подобные абстракции (DPC, Thread) на слабом вычислителе нужно очень аккуратно, ибо чаще всего нецелесообразно

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

А уменьшение периода системного тика неоправданно из-за получаемого высокого оверхеда.

Оверхед у меня действительно большой: 60-80% времени процессор выполняет код, находящийся в обработчике системного таймера..

Может у меня и "криво" всё это получилось. Но по-другому тут не сделаешь ибо условия следующие:
1.F = 4МГц
2.Target MCU = ATmega8515
3.Требуется производить поллинг и "дёргание ногами" портов со стабильной частотой: джиттер периода их отработки не более 1%
4.Требуется чтобы частоты поллинга и "дёргания" были масимально возможными, а значит чтобы период поллинга/дёргания был мимимальным

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

По поводу "кривизны" моего решения ответил выше

Имхо, применять данные механизмы и подобные абстракции (DPC, Thread) на слабом вычислителе нужно очень аккуратно

Да вроде как усё работает (Тьфу, тьфу, тьфу)

Имхо, применять данные механизмы и подобные абстракции (DPC, Thread) на слабом вычислителе нужно очень аккуратно, ибо чаще всего нецелесообразно

Ничего..Вон люди ещё на более "слабых вычислителях" применяют с успехом эти "абстракции".
http://www.telesys.ru/wwwboards/mcontrol/1...es/302464.shtml

При "классической" схеме

Любые схемы - это всего лишь общие рекомендации ..

У меня ядро RTOS так управляет потоками, что процессор и другие ресурсы всегда достаются тому у кого наименьший deadline реакции на событие и все потоки всегда всё успевают сделать .

А значит не смотря на афигенный оверхед у меня RTOS правильная раз она удовлетворяет приведённому мной выше определению операционной системы жёсткого реального времени.

А если бы я следовал классической схеме мне бы пришлось поставить как минимум в 10 раз более мощный (а значит примерно во столько же раз более дорогой) процессор

Сообщение отредактировал Дон Амброзио - Mar 10 2008, 16:51