Начало:
http://electronix.ru/forum/index.php?showt...=29375&st=0

Отсутствие вложенных прерываний иногда может привести к непомерной потребности производительности МК.
Пример:
Есть 8 источников прерываний.
Самым тяжелым случаем будет момент (его нельзя исключать), когда одновременно будут выставлены все флаги запроса прерывания.

Без вложений
Обрабатываться прерывания будут последовательно, в определенном аппаратными средствами порядке. Если окажется что самое критичное прерывание будет последним в этой очереди, то придется жестко контролировать время выполнения всех прерываний. Шаг в сторону -- прерывание потеряно...


С возможностью одного вложения
Самому критичному присваиваем высокий приоритет - поэтому оно будет обработано всегда первым - выигрыш по производительности получается в 8 раз


К чему я это?
К тому, что иметь такую возможность не помешает именно в embedded приложениях, когда требуется "утоптать" в имеющийся аппарат, а не брать монстра.


PS: Вложенные прерывания на некоторых системах достаточно "дороги" за счет потребления RAM, если затруднительно организовать отдельный стек для прерываний.

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

Дык, например, для ARM никаких проблем нет - в безопасном месте обрабочика вставляем функцию типа (вариант для IAR 4.3x):

И живем долго и счастливо с вложенными прерываниями
К RTOS это имеет несколько косвенное отношение - упомянутый TNKernel, cкорее всего, даже без модификации будет работать с такими обработчиками (возможно, сегодня выясню это практически).

Обрабатываться будут в порядке приоритетов и самое приоритетное обработается максимум после завершения одного из предыдуших, а отнюдь не всех семи предыдущих.

Причем здесь поминание слова "производительность"? Почему скромно в 8 раз? А пусть самое первое обрабатывается в 8000 раз дольше самого приоритетного, тогда мы получим "производительность" аж
8008 раз большую, а если написать, что 8 миллионов раз, то...

Прежде всего нужно НЕ РОЖДАТЬ монстра на уровне продумывания системы. И не потребуется "утаптывать".

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

Я где-то читал, что RTOS с preemptive scheduler и разными приоритетами задач есть по сути
софтовая реализация аппаратного многоприоритетного контроллера прерываний. Как вам такая
идея ?

Хорошая идея, но тут есть одно но! Если у вас написано для многопиоритетных прерываний -> вы это переложите на ОСРВ, а если написано на ОСРВ то не факт что переложите на прерывания ибо обработчик прерывания запустился и окончился (все его локальные переменные что были исчезли), а поток может не закончиться никогда(локальные препеменные всегда лежать в его персональном стеке).