Вложенные прерываня Опции

[moonrock]

Всем привет, недавно начал разбираться с LPC2132, среда - Keil uVision,
и вот встал вопрос, как сделать, чтобы прерывания с высшим приоритетом могли прерывать исполнение обработчиков прерываний с низшим приоритетом?

[zltigo]

ARM 7 аппаратно НЕ поддерживает вложенные прерывания

Осталось выяснить КТО аппаратно подерживает сохранение контекстов для КАЖДОГО из
возможных прерываний :-)). На самом деле достоинством является вообще наличие аппаратно переключаемого стека и собственных регистров FIQ и IRQ. Таким образом "софтовая" организация
вложенных прерываний является абсолютно естественной а не каким-то "извращением" являющимся дурной особенностью ARM7.

IMHO,без крайней необходимости с nested interrupt в ARM7/9 лучше не связываться -
весьма коварная штука.

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

[GetSmart]

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

Ага. Скажите прямо, проектировать систему в которой будут сидеть на прерываниях более одного периферийного устройства крайне опасно. Бог его знает, что может произойти. И если в моей программе вдруг потребовалось одновременно обрабатывать все 8 capture-входов, PWM, два UARTа, RTC и пару вшешних прерываний, то это ну очень крайняя необходимость, которая у других никогда не возникает. Причём всё бы ничего, если бы capture не требовали максимально быстрого отклика. А так пришлось все прерывания кроме них сделать вложенными. Гордится этим? Слишком мелко как-то. Я бы гордился скажем 20-ю вложенными прерываниями. Если у вас ничего интересного нет по поводу смешивания вложенных и невложенных прерываний и как с помощью их комбинаций можно оптипизировать систему в целом, то можете говорить и дальше что это плохо и неразумно. Многие с удовольствием послушают.

Сообщение отредактировал GetSmart - Jul 8 2006, 15:26

[zltigo]

И если в моей программе вдруг потребовалось одновременно обрабатывать все 8 capture-входов, PWM, два UARTа, RTC и пару вшешних прерываний, то это ну очень крайняя необходимость, которая у других никогда не возникает. Причём всё бы ничего, если бы capture не требовали максимально быстрого отклика. А так пришлось все прерывания кроме них сделать вложенными.

Ну и где в описанной системе 8 "УРОВНЕЙ ВЛОЖЕННОСТИ" помянутые в ПЕРВОНАЧАЛЬНОМ посте???
В этом черным по белому описан вариант одного уровня, причем его наличие обосновано, хотя и не понятно, почему-бы не использовать для CAP FIQ, если конечно у Вас не дебильноватый контроллер типа STR7..... В принципе именно армовские IRQ+FIQ без дополнительной организации вложенности достаточно хорошо закрывают массу вариантов применения, в том числе и описанный Вами.

[GetSmart]

Ну и где в описанной системе 8 "УРОВНЕЙ ВЛОЖЕННОСТИ" помянутые в ПЕРВОНАЧАЛЬНОМ посте???

Собственно 8 уровней мне не надо было. Они возникают сами по себе при объявлении любого прерывания __nested. Поэтому если в системе 8 прерываний, 2 простых, 6 __nested, то если никак дополнительно не извращаться, будут именно 7 уровней вложенности. А теперь почему они сделаны __nested. Например, после приёма байта по UARTпрямо в прерывании вызывается драйвер связи, который может долго не возвращать управление, ну скажем до 100 мкс. Всё это время он не мешает никаким прерываниям с более высоким приоритетом. А в некоторых случаях (приём полного пакета) он ещё и взводит софтовое прерывание с более низким приоритетом. Так, что как только это прерывание завершится и если ничего более важного не произойдёт, управление вернётся не в основную прогу, а в софтовое прерывание связи. В нём вообще может управление застрять на десятки миллисекунд. И никто не обломается! Никаких критических секций и прочих извращений для этого применять не нужно вообще. Всё продумано и очень просто в применении. Бояться вложенных прерываний - в лес не ходить.

Насчёт FIQ'ов, я всё прекрасно знал. И всё-таки решил сделать так. Всё написано на Си, никаких макросов.

[zltigo]

Они возникают сами по себе при объявлении любого прерывания __nested.

Когда что-то "возникает само по себе" это не радует :-(. А реально никто не мешает для описанного Вами случая в __nested запретить прерывание одного __nested другим ввиду ПОЛНОЙ НЕНУЖНОСТИ сего действия. И я не назвал-бы это "извращением" - напротив. Если-бы в ARMообразных контроллерах могли назначаться одинаковые приоритеты для разных источников, то это вообще реализовывалось без каких-либо дополнительных телодвижений.

А теперь почему они сделаны __nested.

Это не нуждается в дополнительных объяснениях - "надо быстро реагировать на CAP" было вполне достаточно.

Бояться вложенных прерываний - в лес не ходить.

Я не призываю их бояться я сам их использую, просто их не надо использовать без необходимости и уж точно бороться с возникающими "сами по себе" побочными эффектами в виде вложенности в местах, где это без надобности. Ибо, как минимум, ведет к дополнительным затратам временных ресурсов и памяти. При этом можно получить неожиданные проблемы (особенно при дописывании через годик-другой) при работе обработчиков с общими ресурсами. При совсем уже чрезмерном увлечении длинными вложенными обработчиками можно и повторный вызов обработчика схлопотать, от которого тоже надо защиту вписывать. В общем оно это надо без крайней необходимости?

Насчёт FIQ'ов, я всё прекрасно знал. И всё-таки решил сделать так.

Т.е. для конкретного описанного случая запутаннее и тормознее :-( без явной на то необходимости, а только по причине наличия в EWARM
удобного ключевого слова __nested :-(.