Вложенные прерывания в embedded RTOS, по следам обсуждения TNKernel Опции

[spf]

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

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

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

Код

1-2-3-4-5-6-7-8

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

Код

8(!)-1-2-3-4-5-6-7 - все одновременно
1>8(!)<1-2-3-4-5-6-7 - запрос 8-го чуть позже, во время выполнения обработчика первого.

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


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