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

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

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

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

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

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

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

Решил делать так:
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 все правильно сказал