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

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

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

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

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

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

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

И ещё одно отступление сделал от "классической" схемы построения вытесняющих 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