Вложенные прерывания в 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, если затруднительно организовать отдельный стек для прерываний.

[zltigo]

Без вложений
Обрабатываться прерывания будут последовательно, в определенном аппаратными средствами

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

- выигрыш по производительности получается в 8 раз

Код

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

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

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

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

[v_shamaev]

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

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

[yuri_t]

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

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

[ddiimmaa]

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

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