У вас похоже на типичную ошибку планирования ресурсов.
В нормально спланированной системе нет проблем недостатка таймеров.
Общее время обслуживания всех реалтайм задач за время системного тика должно быть не больше 70% его продолжительности.
Фиксация точного времени поступления событий осуществляется capture логикой.
Если нужно генерировать сигналы с точным временем, то на это есть compare логика в таймерах.
Переходите на Cortex M3 и не будете иметь проблем.
Если реально времени системного тика не хватает на обработку всех прерываний, то используют 2-х и более процессорные схемы:
http://aly.ogmis.lt/OpenProjects/ARMDominator4/ARMD4.htm Цитата(Дон Амброзио @ Mar 6 2008, 11:20)
Мне требуется в обработчике системного таймера вести поллинг сигнала (потому что в MCU таймеров всего 2 (ATmega8515): один используется для ШИМ, а другой как сист.таймер).
Для этого требуется маленькая погрешность точек на временной оси взятия отсчётов сигнала.
Из-за того, что существуют прерывания, приоритет которых выше прерывания таймера, приходиться их запрещать (дабы джиттер не увеличили сверх допустимого значения) и осуществлять их поллинг в обработчике сист.таймера. Из-за чего ISR системного таймера ещё больше "пухнет" в размерах. Из-за этого приходиться уменьшать частоту сэмплирования сигнала, что ухудшает качество девайса.
А как вообще в операционках решают задачу когда прерывание с более высоким программным приоритетом обслуживания имеет низкий аппаратный приоритет. Как для него добиваются того, что даже при наличии прерываний с аппаратным приоритетом выше его приоритета LatencyTime было для него в допустимых пределах?
Можно ли добиться малого джиттера системного таймера, если есть прерывания с приоритетом выше сист. таймера
Mar 6 2008, 06:50
