Кто какими критериями пользуется выбирая место размещения вызовов функций? В главном цикле, обработчике прерываний или по условию из глав. цикла.
У меня в программе есть функции которые имеет смысл вызывать при прерываниях: АЦП, УАРТ,.... если они будут в глав. цикле - увеличится длительность цикла. если в обработчике, то длительность обработки, если по условию, то нужно больше создавать программных флагов (по условию). Кто как решает?

Вытесняющая RTOS вам поможет.
Какой процессор?

Если в прерываниях не используютчя таймеры (то есть выполнение обработчика не критично по времени), то я обычно обрабатываю данные (UART, ADC) в обработчике прерывания, выставляю флаг готовности, если все ок...

мк AVR. и операционка отпадает

вот вариант
http://scmrtos.narod.ru/

Немного не понятно.
Если в микроконтроллерах,то в прерывании после анализа флагов.
Если в приложении,например Windows,то по каждому событию.Если АЦП не
задействует аппаратное прерывание , можно создать отдельный поток и для
него событие.

Я эту проблему решал (на AVR же) путем введения третьего дополнительного уровня, промежуточного между головной программой и обработчиком прерываний. Идея в следующем:
- обработчик прерываний выполняет минимально необходимые действия (например, читает UDR), после чего вызвает обработчик среднего уровня. Ему передаются как параметры указатель на функцию, которую необходимо выполнить и, как опция, параметр для этой функции (например, считанное из UDR значение).
- при вызове обработчик среднего уровня записывает принятые параметры в FIFO и смотрит, что было прервано - головная программа или выполнение функций из этого FIFO (по спец.флагу). Если головная программа, то флаг взводится и запускается выполнение из FIFO. Если же было прервано выполнение из FIFO (флаг уже стоял), то управление туда и возвращается.
- выполнение из FIFO идет при разрешенных прерываниях, отуда выбирается указатель на очередную функцию и параметр для нее, затем функция вызывается. После возврата из функции лезем в FIFO за следующей и, если там пусто - сбрасываем флаг и возвращаем управление головной програме.

Это Вы соорудили не что иное как вытесняющую RTOS. Только двухзадачную. Поскольку задач всего две - приоритетная и фоновая, то планировщик получается максимально простой - фактически он отсутствует. Далее, если бы Вы завели не один такой FIFO, а несколько, то можно было бы реализовать несколько таких промежуточных уровней - несколько задач. И осталось бы только алгоритм порядка перебора этих FIFO реализовать.

Кстати, а как реализовывали вызов этого "среднего" уровня? На каком МК? На AVR?

На AVR (mega103/128). Только RTOS - несколько громкое название. Так, многозадачный мониторчик, причем невытесняющая многозадачность там есть для фонового уровня - потоки сдают мониторчику управление вместе со списком событий, по которым их следует "разбудить" путем вызова функции int WAIT(...). В случае наступления какого-либо события эта функция (а на самом деле монитор) возвращает управление и номер наступившего события.
А описанный мною ранее средний уровень я многозадачным назвать не могу (как это делают в рекламе подобных игрушек), т.к. многопоточность там не реализована. Долго это - переключать потоки при обработке прерываний. Скорее, средний уровень - обработчик отложенных прерываний, хотя, конечно, вызываемые через FIFO функции относятся к самым разным задачам.

Если не жалко отдать 5-10% циклов на overhead планировщика (зависит от количества задач и частоты переключенич контекстов) то однозначно RTOS. Даже для AVR. В результате будет проще спланировать приоритеты, порядок доступа к ресурсам и т.д. Очень рекомендую uC/OS (www.micrium.com). Порт для AVR у них есть.
А если по сути вопроса - в обработчиках прерываний лучше делать как можно меньше. По быстрому обработать железо и выставить флаг. Основной цикл проверит флаг (и его приоритет) и передаст управление функции. Если все делать в ISR то real-time реакция системы может стать плохопредсказуемой.

Спасибо за ваши мнения. Интересный вопрос я задал. да и ответы интересные. спасибо

Еще очень хороший вариант
http://www.jacos.narod.ru/

Кооперативная.

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

Я поступил несколько иначе, обработчики прерывания - выполняют необходимые действия только со своими собственными очередями, т.е. читая, например, UDR обработчик складывает принятые данные в свой FIFO и утанавливает программный флаг "присутствия новых данных" для своего FIFO.
Промежуточный же уровень у меня - это диспетчер, которой работает в основном цикле программы, и запускает заданные ему при инициализации функции(задачи) взависимости от условий сформированных обработчиками прерываний (изменение времени, наличие новых данных во входных очередях UART(ов)/ADC и т.п.).

Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий 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 будет выше всех остальных прерываний, тогда вообще нельзя спрогнозировать реакцию системы на другие события..

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