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

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

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

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

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

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

[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