Всем привет, недавно начал разбираться с 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: за раскрытие темы подводных камней

В ядре ARM7 нет. Если нужна скорость - используйте _сразу_ полную или частичную таблицу.

Знаю, что нет, поэтому (повторю вопрос)

Написал такое, но асм для 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:


Про таблицу не понял, ну младшую 1 выделить не сложно, а дальше...

Таблица содержащая номер бита или _сразу_ указатель на функцию.
Если предполагается работа с полноразрядным числом, то можно для экономии размера таблицы использовать сокращенную 16, 8 или 4 битную.
0x0 ?
0x1 0
0x2 1
0x3 0
0x4 2
0x5 0
0x6 1
0x7 0
0x8 3
0x9 0
......

Здесь посмотрите. Пост №48 by sergeeff.

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

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

А вот и не подеретесь
Zltigo - а чего в ентих STR дебильного ? Просто интересно.. Вкратце, пару слов

Там на FIQ вешаются _только_ Watchdog и Timer0 - абсолютно необъяснимая дурь.

Да и в остальном контроллер прерываний там заметно примитивнее :-( по отношению к прочим сделанным производителями чипов по ARMовским лекалам.

Да уж... Мне как-то повезло... Ни разу FIQ не надо было и вложенность тоже... Отсюда гигантская дыра в знаниях =)

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

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

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

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

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

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

Повторный вызов не схлопотать. Запрещаются все приоритеты равные и ниже текущего. А то, что нельзя делать одинаковые приоритеты я и сам жалею. Помню как удобно было на 51/52 процах с трёхуровневой системой прерываний. Быстро и удобно.

В данном вопросе только один минус - лишняя многоуровневость. Но гораздо больше плюсов. Особенно быстрое время реакции на все прерывания с учётом приоритетов. А медленные софтверные прерывания вообще не сделать без вложенности.


Не-а. Я бы советовал не использовать обычные прерывания без особой необходимости. Особенно длинные или использующие много стека.

блин, тут все такие умные, один умней другого, аж страшно задавать следующий глупый вопрос , но всё же задам: мой компилятор(keil uVision) не знает ключевое слово __nested, чем вы пользуетесь?

1. Я не полльзуюсь Keil.
2. А зачем своими руками выдрав и отпостив из кейловских рекомендаций два макроса спрашивать
чем пользоваться в Keil???

Не сильно страшно?






Без коментариев.

Я старым (уже) IAR 4.20
Тут где-то выкладывали ссылку на 4.30, а может даже и на 4.40.



Без коментариев.

Спасибо, то, что надо.

Keil не нужно __nested для описания вложенных прерываний. Достаточно пользоваться макросами IENABLE и IDISABLE в функции обработчика прерывания. Очень хорошие примеры вложенных прерываний (там почти все обработчики сделаны этими макросами с поддержкой вложенных прерываний) есть у филипса в примерах кода к lpc21xx (адрес не знаю, искать "code.bundle.lpc213x.lpc214x.uvision.zip").

В качестве примера

Сами макросы тоже просты

Скорее всего я чего-то не понимаю, но все же: как может вызваться в этом примере вложенное прерывание если VICVectAddr = 0; стоит в самом конце обработчика? Ведь пока не сделан VICVectAddr = 0 контроллер не выдаст адрес следующего обработчика?

До записи VICVectAddr может быть вызвано только прерывание с более высоким приоритетом.

Проверить достаточно легко, можно и о PrimeCell почитать первоисточник. Но по логике вещей так быть не может, ибо в этом случае при возникновении последовательно прерываний от разных источников будут потеряны все низкоприоритетные, если процесс обработки не успеет считать значение из VicVectAddr и оно будет перезаписано более приоритетным адресом обработчика. В общем как ни крути именно процедура произвольной записи в VicVectAddr логично разрешает занесение нового (вне зависимости от его приоритета) значения в этот регистр. Ну а примеры, как это почти всегда :-( бывает просто фуфло.

Вот и почитайте:

Достаточно убедительно и в такой трактовке работоспособно, хотя настораживает фраза "the same priority", которых быть не должно.
Короче желательно проверить электроникой, что и сделаю сегодня.

Проверено!
Действительно, чтение " Vector Interrupt Address Register" несет дополнительную функциональную нагрузку в виде перетасовки приоритетов и даже без последующей записи
позволяет функционировать более приоритетным прерываниям. Это хорошо, обязательно использую!
Эксперимент проводился на LPC2148 у которого контроллер прерываний от ARM прикручен.

Подскажите, если кто знает, пример кода для обработчика вложенных прерываний для AT91SAM7A3, компилятор Keil.

Из примеров на сайте atmela Исходя из примера вложенность прерываний делается просто.
В филипсах таким вопросом не озадачивался, поэтому не совсем понятно зачем народ здесь копья ломает

Мои пять копеек вопроса про вложенные прерывания. на LPC2148 делаю захват CAP0 по таймеру TIMER0.
По отдельности от сигнала подаваемого на все 4 входа захвата( синхронный фронт на все 4 входа) - все работает - счетчик импульсов тикает.
Когда все вместе ( захватывается только 1-он первый канал (((
пишу под IAR. мой код прерываний - т.к. инициализация корректна

Ну и как здесь будет реализована вложенность прерываний? ято я не так делаю ? (((

В этой строчке вы сбрасываете не только этот флаг, но и все остальные. Потому что доступ к битовому полю происходит как операция "чтение-модификация-запись" чтобы не испортить остальные поля. Откуда же компилятору знать, что для этого регистра так делать нельзя. Это раз.
Второе - непонятно, зачем вам тут вложенные прерывания. Разрешаются вложенные прерывания только более высокого приоритета, т.е. в этот же обработчик вы не попадете.
Третье - вынесите свой irq_handler в ассемблерный файл в виде команды LDR PC,[PC, #-0x0FF0] прямо на векторе прерывания, а VICVectAddr = 0 и __irq __arm перенесите в каждый обработчик. Вот тут пример для SAM7, для LPC меняются имена регистров. Это позволит компилятору генерить максимально эффективные (короткие) прологи/эпилоги и существенно повысит скорость обработки прерываний, а вам позволит использовать __nested только для тех обработчиков, в которых он действительно нужен (например, в самых приоритетных он не нужен - прервать такой обработчик некому - и только замедляет эти самые важные обработчики).
Четвертое - вам надо в этом обработчике организовать цикл do{}while(T0IR);

Повторный вызов можно схлопотать элементарно. VicVectAddr=0 открывает ВСЕ прерывания. Нужно явно маскировать и восстанавливать приоритеты.

Ошибаетесь:

Если мы обсуждаем версию ARM PrimeCell, используемую в большинстве LPC, то ошибаетесь Вы. Действительно, при чтении VicVectAddr, контроллер повышает приоритет разрешенных прерываний до уровня текущего прерывания. Это обеспечивает правильный вход в стэк прерываний, но только до первой записи в VicVectAddr, что сбрасывает логику контроллера. Таким образом, незавершенные ISR могут прерываться прерываниямм с более низким приоритетом, если прерывания этого типа разрешены в CPSR. Макросы Keil'a просто открывают прерывания. Никакого "Handle nested interrupt" в них нет. VicSWPriorityMask должен быть использован для правильной реализации вложенности.

Во-первых, и так понятно, что речь шла о pl190, у pl192 этот регистр называется VICADDRESS.
Во-вторых читаем (pl192):

и еще:

И как получается вывод

?

Программное управление приоритетами было введено в дополнение к аппаратному, и никак его не отменяет:

Убедил. Был неправ. Вспылил.

Половину не понял из того, что написано...
Хотя вопрос сильно интересует.
Проц. LPC2364
INT2(Р2.12) & INT3(Р2.13) подключены как счетные входы. Частоты примерно 400-500 Гц и 200-250Гц.

Обработчики такие:

__irq __nested __arm void EINT2_Handler (void)
{
EXTINT|= EINT2; /* clear interrupt */
__enable_interrupt(); /* handles nested interrupt */
//***********************************************************

ssf_o++;

//***********************************************************
VICVectAddr = 0; /* Acknowledge Interrupt */
}
__irq __nested __arm void EINT3_Handler (void)
{

EXTINT|= EINT3; /* clear interrupt */
__enable_interrupt(); /* handles nested interrupt */
//***********************************************************
count_msr++;


//***********************************************************
VICVectAddr = 0; /* Acknowledge Interrupt */
}

Короче работает только один счетчик , прерывание которого имеет больший приоритет.
Если убираю _nested и __enable_interrupt(); дела не меняет, тоже самое.

Тоже самое на 51-х, Меге и NEC работает прекрасно. Вопрос КАК извернуться? Объясните, пожалуйста , что не так...

Когда ничего не помогает, прочтите, наконец, инструкцию.

This bit is cleared by writing a one to it, except in level sensitive mode when
the pin is in its active state.

и

стандарт языка еще, про операцию |=

М-да. Сказать нечего... Заменил |= на = и все заработало.
Запарился совсем. Спасибо.