Цитата
Не скажите, предсказуемость наоборт нарушится.
Чем больше Latency Time тем дальше система отдаляется от Real Time.
"Ничего я на это не скажу, а только отвечу..."
Жесткое РВ, это когда можно рассчитать время обработки события, максимальное и минимальное. И все.
Большое это время или маленькое - не имеет значения. Для ПИД рег. температуры печи и 100 мс достаточно, а для обработки изображения и мкс не хватит. Главное, что разработчик может сказать: "событие Х будет обработано в течение времени не более Y" - это и есть жесткое РВ. Возможны варианты, типа, "событие Х начнется обрабатываться через время не более Y", или "событие Х в среднем обрабатывается через время Y" (мягкое РВ).
Вывод: Interrupt Latency есть важный показатель качества, но не влияет на собственно РВ.
Если у Вас есть другие соображения - предлагаю обсудить отдельно, поскольку это, в общем, не относится к теме.
По теме:
Если надо быстро, то на AVR можно попробовать сделать следующее:
1. Использовать вложенные прерывания (типа в обработчике UART разрешать прерывания от ADC или, например, обработку протокола осуществлять в обработчике прерывания от UART, но с разрешенными прерываниями). Этот подход - самый экономный по ресурсам и с наименьшей реакцией, может применяться если нет спорадических событий. Требует внимательности - стек и т.п.
2. Можно сделать монитор, либо по опросу (выставлять флаг и обрабатывать), либо вытесняющий - выставлять флаг какого-нибудь неиспользуемого прерывания, тогда по выходу из текущего, обработчик сразу же зайдет в обработчик.
На будущее, думаю, лучше изучить какую-либо RTOS:
вытесняющие:
scmRTOS или uCOS или
C kernel или
XMKкооперативные:
Salvo, JacOS,
procдругие
NesosУспехов!
Основной цикл или обработчик прерываний, Что лучше утяжелять?
Oct 4 2005, 04:46
