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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

Вторая фраза противоречит первой: получается из Ваших слов в 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

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

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

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


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



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





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

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


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



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

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

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

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

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

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

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