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

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

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

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

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

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

[Непомнящий Евген...]

Например: во всех нетривиальных аппаратных прерываниях выполняете только установку неких флагов. Затем с нужным вам приоритетом выполняете действия по этим флагам.
Плюсы - настраиваете приоритеты как вам угодно.
Минусы - дополнительное время\код на обработку флагов.

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

Минусы - дополнительное время\код на обработку флагов.

Вот-вот.. И я о о том же. Обработчик системного таймера "пухнет", а кроме того, становиться невозможной увеличение частоты прерываний сверх частоты прерываний системного таймера. А с учётом того, что он "пухнет" (а значит и, соответственно, уменьшается частота прерываний) результат получается плачевный: я успеваю обработывать прерывания, следующие не чаще чем 1 раз в 1000мкС. А желательно бы было "успевать" обрабатывать прерывания с минимальным временем следования прерываний раз в 100мкС

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

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

[AlexandrY]

У вас похоже на типичную ошибку планирования ресурсов.
В нормально спланированной системе нет проблем недостатка таймеров.
Общее время обслуживания всех реалтайм задач за время системного тика должно быть не больше 70% его продолжительности.
Фиксация точного времени поступления событий осуществляется capture логикой.
Если нужно генерировать сигналы с точным временем, то на это есть compare логика в таймерах.
Переходите на Cortex M3 и не будете иметь проблем.
Если реально времени системного тика не хватает на обработку всех прерываний, то используют 2-х и более процессорные схемы: http://aly.ogmis.lt/OpenProjects/ARMDominator4/ARMD4.htm

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

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

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

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

Переходите на ....

... то используют 2-х и более процессорные схемы...

Просто "Железо" уже разработано. И надо использовать по максимуму его возможности.

P.S. Хотя конечно в следующей разработке будут учтены все "узкие" места. Но это в СЛЕДУЮЩЕЙ разработке. А мне нужно как-то выкручиваться с уже имеющемся "железом"

У вас похоже на типичную ошибку планирования ресурсов.
В нормально спланированной системе нет проблем недостатка таймеров.

Тут даже проблема не в недостатке таймеров, а в том, что аппаратный приоритет прерывания системного таймера нельзя менять. В результате чего у меня получается, что прерывания имеющие низкий ПРОГРАММНЫЙ приоритет имеют высокий АППАРАТНЫЙ приоритет. Вот с этим главный гимор

[arttab]

можно повысить рабочию частоту мк и за счет этого уменьшить джитор.
но правильнее определить приоритетную задачи и "подвинуть" остальные. Это Вам уже советовали. есть прерывание, вызывающте обработку сигнала по таймеру или по изменению на выводе. остальные действия по флагам или по разрешению др. прерываний на допустимый временной интервал (USART, I2C...).

[Baser]

Тут даже проблема не в недостатке таймеров, а в том, что аппаратный приоритет прерывания системного таймера нельзя менять. В результате чего у меня получается, что прерывания имеющие низкий ПРОГРАММНЫЙ приоритет имеют высокий АППАРАТНЫЙ приоритет. Вот с этим главный гимор

Не понял вашего высказывания. У АВР-ок только один уровень прерываний. И соответственно, АППАРАТНЫЙ приоритет прерываний работает только тогда, когда ОДНОВРЕМЕННО происходит больше одного события, требующего обработки прерывания. А в случае, когда программа УЖЕ находится в прерывании, его не может прервать ни одно другое, даже с самым высоким аппаратным приоритетом.

Это возможно только при организации программных вложенных прерываний. Применял вложенные прерывания именно для уменьшения джиттера при динамической индикации. Правда там не было РТОС.

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

У АВР-ок только один уровень прерываний.

АППАРАТНЫЙ приоритет прерываний работает ...

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

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

Сообщение отредактировал Дон Амброзио - Mar 9 2008, 00:42

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

Решил делать так:
1.Запретить все прерывания, кроме прерываний системного таймера.
2.Создать в обработчике системного таймера некий микропоток, который будет вести поллинг для всех других потоков и обеспечивать малый джиттер моментов поллинга (делаем это так: вошли в обработчик; скомпенсировали джиттер момента входа в обработчик введя цикл простоя до LatencyTimeMax; сделали поллинг всего что требуется другим потокам)
3.Ввести в обработчик 3-4 микропотока, которые обрабатывают каждый свои данные, полученные микропотоком, произвёдшим поллинг

Минусы:
Обработчик системного таймера "распух" почти до 1800 тактов процессора

Плюсы:
1.Зато у меня теперь аж сразу 4 потока имеют джиттер моментов поллинга не более 10 тактов. Таким образом обеспечивается стабильность частоты поллинга 10/1800*100 = 0,55%, что вполне устроит даже самые требовательные к разбросу частоты поллинга приложения (например реализация программного UART)
2.Частота поллинга получается всё же достаточно высокой (1 поллинг в 1800 тактов процессора) сразу у 4-х потоков

Сообщение отредактировал Дон Амброзио - Mar 9 2008, 09:37

[AlexandrY]

Что-то у вас совсем там плохо.
На атмеге в нормальной RTOS все время переключения контекста занимает не более 640 тактов.
А выполнение ISR по системному тику и того меньше.
Один сигнал можно посадить на Input Capture Unit, т.е. прецизионно отслеживать вообще без всякого полинга. Остальные посадить на прерывания от Compatre Unit, т.е. делать полинг хоть каждые 10 мкс. (и джитер доли мкс. )
А ISR обслуживания RTOS делается обычно самой низкоприоритетной и ничего туда дополнительно не вставляется.
Только не надо аппелировать к вашим терминам "микропоток", "системный таймер"
и т.д. Этими понятиями обозначают обычно нечто иное чего не может быть в атмеге.

Решил делать так:
1.Запретить все прерывания, кроме прерываний системного таймера.
2.Создать в обработчике системного таймера некий микропоток, который будет вести поллинг для всех других потоков и обеспечивать малый джиттер моментов поллинга (делаем это так: вошли в обработчик; скомпенсировали джиттер момента входа в обработчик введя цикл простоя до LatencyTimeMax; сделали поллинг всего что требуется другим потокам)
3.Ввести в обработчик 3-4 микропотока, которые обрабатывают каждый свои данные, полученные микропотоком, произвёдшим поллинг

Минусы:
Обработчик системного таймера "распух" почти до 1800 тактов процессора

Плюсы:
1.Зато у меня теперь аж сразу 4 потока имеют джиттер моментов поллинга не более 10 тактов. Таким образом обеспечивается стабильность частоты поллинга 10/1800*100 = 0,55%, что вполне устроит даже самые требовательные к разбросу частоты поллинга приложения (например реализация программного UART)
2.Частота поллинга получается всё же достаточно высокой (1 поллинг в 1800 тактов процессора) сразу у 4-х потоков

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

Что-то у вас совсем там плохо.
На атмеге в нормальной RTOS все время переключения контекста занимает не более 640 тактов.

У меня переключение контекста (точнее смена текущего running-потока) занимает для самых "тяжеловесных" потоков порядка 150-ти тактов

А выполнение ISR по системному тику и того меньше.

Это зависит от того, что нужно делать в обработчике. Если только обслужить датчик реального времени, то тогда да..

Один сигнал можно посадить на Input Capture Unit, т.е. прецизионно отслеживать вообще без всякого полинга. Остальные посадить на прерывания от Compatre Unit, т.е. делать полинг хоть каждые 10 мкс. (и джитер доли мкс. )

Я же говорю, железо уже готово и MCU = ATmega8515. Таймер T1 используется для ШИМ-а, а T0 как системный таймер. Больше таймеров нет.

А ISR обслуживания RTOS ..

Что за "зверь" такой? Никогда не слышал о нём

Что-то у вас совсем там плохо.

в нормальной RTOS ...

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

Давайте только поменьше негатива.. Может у меня и "НЕНОРМАЛЬНАЯ" (по Вашим понятиям) RTOS, давайте всё же больше говорить по существу, а эмоции оставим в стороне

P.S. Вернёмся всё же к "нашим баранам": как обеспечить малый джиттер таймера T0 в ATmega8515 если его прерывание имеет аж 13(!!!) приоритет (считая что 0 - это самый высокий приоритет)

Один сигнал можно посадить на Input Capture Unit, т.е. прецизионно отслеживать вообще без всякого полинга.

Ага... Можно... А как же тот факт, что преывания INT0 и INT1 в ATmega8515 имеют более высокий приоритет , чем TIMER1CAPT? Т.е. вектор TIMER1CAPT стоит на 3-м месте после векторов INT0 и INT1..



А как Вы сделаете это на ATmega128 у которой вектор TIMER1CAPT стоит вообще на 11-м месте ?

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

[vshemm]

P.S. Вернёмся всё же к "нашим баранам": как обеспечить малый джиттер таймера T0 в ATmega8515 если его прерывание имеет аж 13(!!!) приоритет (считая что 0 - это самый высокий приоритет)

Как можно быстрее разрешать прерывания в обработчиках прерываний 0-12, а сам обработчик таймера выполнять при запрещенных прерываниях (последнее на джиттер не влияет)
Ну или как Вы сделали.
Baser все правильно сказал

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

Как можно быстрее разрешать прерывания в обработчиках прерываний 0-12,

Даже если стараться "быстрей", то в среднем получиться 50 тактов на один обработчик. Т.е. в худшем случае мы имеем LatencyTime 13 x 50 = 650 тактов.

[vshemm]

Даже если стараться "быстрей", то в среднем получиться 50 тактов на один обработчик. Т.е. в худшем случае мы имеем LatencyTime 13 x 50 = 650 тактов.

Да, и это если за 650 тактов снова не сгенерится высокоприоритетное прерывание

Даже если предположить, что у таймера самое высокоприоритетное прерывание, джиттер будет не меньше времени выполнения самого длинного куска кода под запрещенными прерываниями. По Вашим подсчетам это 50 тактов.

[SSerge]

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

[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