Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time.
А вот Interrupt Latency возрастет.
Вопрос в том, чем пожертвовать...

Не скажите, предсказуемость наоборт нарушится.
Чем больше Latency Time тем дальше система отдаляется от Real Time.

Это как посмотреть. Коллега TMX совершенно правильно заметил, что если все делать в прерываниях, то будет жесткий real-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
Успехов!

proc, вроде, всегда вытесняющей была.

И осталась, собственно, моя ошибка...

Если не возражаете, давайте посмотрим на это так:
пусть есть обработчик прерывания X, который при определенных условиях выполняется за N секунд и обеспечивает RT реакцию на событие X при Tx(время реакции) <= 10*N, и есть обрабочик прерывания Y который выполняется за время M < N секунд, и тоже не нарушает требования к RT при Ty <= N.

Если обработку выполнять непосредственно в обработчких прерывания и при одновременном возбуждении прерываний X и Y "победит" обработчик прерывания X, то система перестанет быть RT, т.к. реакция на второе событие будет Ty = N + M.

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

Я хочу сказать, что разумно не прибегать к крайностям, а найти компромисс, между полной обработкой событий в прерываниях и полностью отложенной обработкой событий в основном цикле программы.

Сообщение отредактировал defunct - Feb 14 2006, 12:20