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

А никак. Прерывания всего два IRQ и FIQ. Есть конечно разные приоритеты в VIC - но их смысл только в том, какое из нескольких прерываний (если случилось несколько) будет вызвано при разрешении прерываний.

Ну, не правда. Вложенные прерывания возможны. Чтоб приоритеты - надо будет маску прерываний ручками подправлять.
В книге, которая про ARM LPC по-русски (забыл как называется, под рукой нет) это рассматривается (поищите по конфе).

А заодно (почти в тему) - вот попадаю я в обработчик IRQ по умолчанию и хочу перевести бит-флаги в номер прерывания (чтоб по таблице функцию-обработчик найти), т.е. мне надо узнать позицию (номер бита) младщей единицы (в XScale инструкция CLZ есть, а в LPC?).

Написал такое, но асм для ARM я почти не знаю, может кто подчкажет как оптимизировать?

/* in: r3 - bit mask */
/* out: r1 - int num */
MOV r1,#0
findirqstart:
AND r4, a3, #1
CMP r4, #0
BNE findirqend

ADD r1, r1, #1
MOV r3, r3, lsr #1
B findirqstart
findirqend:

как я понимаю, такое ограничение накладывает контроллер прерываний филипса, а есть ли вообще контроллеры, которые это позволяют? Ведь, если я не ошибаюсь, такое может делать AVR...

Извращенцы вы тут все. Говорят о том, что не знают. Даже помогать после этого не хочется.

На АРМе это всё делается элементарно. Почитайте в хэлпе об __nested
Может потом на вопросы отвечу.

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

да... был неправ. Всем спасибо, век живи - век учись

Всем большое спасибо, а вот тот ответ, который я хотел услышать:
ARM 7 аппаратно НЕ поддерживает вложенные прерывания, но обеспечить их можно софтварным путём, используя следующие асмовые макросы
#define IENABLE /* Nested Interrupts Entry */ \
__asm { MRS LR, SPSR } /* Copy SPSR_irq to LR */ \
__asm { STMFD SP!, {LR} } /* Save SPSR_irq */ \
__asm { MSR CPSR_c, #0x1F } /* Enable IRQ (Sys Mode) */ \
__asm { STMFD SP!, {LR} } /* Save LR */ \

#define IDISABLE /* Nested Interrupts Exit */ \
__asm { LDMFD SP!, {LR} } /* Restore LR */ \
__asm { MSR CPSR_c, #0x92 } /* Disable IRQ (IRQ Mode) */ \
__asm { LDMFD SP!, {LR} } /* Restore SPSR_irq to LR */ \
__asm { MSR SPSR_cxsf, LR } /* Copy LR to SPSR_irq */ \

и втыкать их перед и после того кода обработчика прерывания более низким приоритетом, который мы хотим прерывать
ещё раз всем спасибо

IMHO,без крайней необходимости с nested interrupt в ARM7/9 лучше не связываться -
весьма коварная штука. Ну а если все таки без этого никак, рекомендую использовать
код из книги A.Sloss,D.Symes,C.Wright, ARM System Developer's Guide - Designing and
Optimizing System Software

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


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

А вот это не советую. Лучше потратить чуть больше времени, и оформить вход и выход из прерывания в виде ассемблерного модуля. В этом случае результат не будет зависеть от компилятора и степени вашего с ним взаимопонимания.

Те же, кто не хочет использовать много асма, могут писать всё на Си и при этом не бояться что что-то плохо будет работать. Это не так. У меня во многих прогах уровень вложенности может доходить до 5-8 и всё работает стабильнее некуда. На асме написан только стартап файл. Поэтому рекомендую, если в программе полезны вложенные прерывания - используйте их наздоровье. Самые критичные прерывания разумеется должны быть непрерываемыми (без __nested). А так, в АРМ7 всё сделано красиво, если кто не понимает почему, их проблемы. Да, и ещё. Прерывания без __nested работают на стеке IRQ|FIQ. А объявленные с __nested работают на стеке основной программы, и ещё в стеке IRQ|FIQ дополнительно занимают 3-4 слова.

Нашли, чем гордится :-(((

Ну на принципиальную нестабильность механизма вложенности никто и не жаловался...
Если у Вас простейшая системка, хоть и 8 прерываниями, но простейшая с мало или не зависящими от результатов работы друг друга обработчиками, то проблем не будет особых. Ну а если нужно будет разруливать все нюансы взаимодействия недозавершенных обработчиков с их прервавшими и т.д., то уже потенциальных ошибок много больше :-(. Разруливание опять таки в обработчиках, что есть дополнительный код и время.

Ага, и это есть хреново, ибо когда у Вас единственная основная программка с единственным стеком, то
оно и ладно, а если у меня их количество десятками исчисляется? Прикажете в стеке каждой
заложить место для стеков многочисленных ее прервавших? Причем поскольку необходимость вложенности перерываний почти всегда следует из громоздкости обработчика, то и требования к размеру стека скорее всего будут заметными :-(.

В общем случае нужно СИЛЬНО думать и все взвешивать перед тем как использовать вложенные прерывания.

А на мой вопрос про завменитель CLZ кто-нить может ответить?

Я лишь предложил способ, пригодный для использования на любом компиляторе. Слово __nested ADS, например, не знает.


Могли бы уже и сами посмотреть список команд для архитектуры V4. Нет там прямой замены.

P.S. ztigo: за раскрытие темы подводных камней