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

Вытесняющая 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 и т.п.).