Форум разработчиков электроники ELECTRONIX.ru > Вложенные прерывания в embedded RTOS

spf

Apr 4 2007, 06:56

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

dxp

Apr 4 2007, 08:59

Цитата(spf @ Apr 4 2007, 10:56)

Отсутствие вложенных прерываний иногда может привести к непомерной потребности производительности МК.
Пример:
Есть 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, если затруднительно организовать отдельный стек для прерываний.

Это все классно, когда есть аппаратная поддержка такой схемы, как в твоем любимом

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

VslavX

Apr 4 2007, 09:32

Цитата(spf @ Apr 4 2007, 06:56)

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

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

Код

        public    irq_Reenable
irq_Reenable:      mov    R1, LR
        mrs    R2, SPSR
        mrs    R0, CPSR
        bic    R0, R0, #NOINT
        msr    CPSR_c, R0
        nop
        nop
        nop
        orr    R0, R0, #NOINT
        msr    CPSR_c, R0
        msr    SPSR_cxsf, R2
        mov    PC, R1

И живем долго и счастливо с вложенными прерываниями

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

zltigo

Apr 4 2007, 09:41

Цитата(spf @ Apr 4 2007, 05:56)

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

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

Цитата

- выигрыш по производительности получается в 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

Apr 4 2007, 10:20

Цитата(zltigo @ Apr 4 2007, 10:41)

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

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

yuri_t

Apr 4 2007, 12:02

Цитата(v_shamaev @ Apr 4 2007, 10:20)

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

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

ddiimmaa

Dec 14 2008, 13:09

Цитата(yuri_t @ Apr 4 2007, 16:02)

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

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