Доброго всем дня.

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

Также заметил что SWI только IRQ запрещает... FIQ опять возможен?

Почему нет ? Книжку артина Тревора почитайте:
http://lord-n.narod.ru/walla.html

Да, да, да, именно эта книжка меня к таким вопросам и подвела. Прямого ответа на мой вопрос там нет, а косвенного не могу найти

В этой части ARM7TDMI и ARM926EJ одинаковы?

В мануалах всё чётко прописано. FIQ запрещается автоматически только самим же FIQ, а значит, может произойти при выполнении любого другого обработчика (если программист, конечно, ручками FIQ не запретил).

На то он и FIQ

смотрите файл-скрипт запуска на асме там для каждого режима выставляется флаг I и F у вас какой контроллер?

контроллер - ARM926EJ

под отладчиком можно видеть что IRQ и SWI ставят 1 в бит I (т.е. зпрещают IRQ) и если FIQ разрешены, то их бит F=0, а стало быть FIQ может быть...

Наверное биты I и F и дают ответ на мой вопрос. Ежели я внутри IRQ обнулю I, то вложенные прерывания тут как тут

Сейчас в IRQ я ручками запрещаю FIQ на время обработчика IRQ (после разрешаю)... Пришлось сделать так, что только одно прерывание существует единовремменно, покуда имеется разделяемый ресурс который используется в основной программе, а также в IRQ и FIQ...

Для каждого режима свой CPSR регистр. При запуске туда заносят состояние флагов I и F
перепишите скрипт запуска установите нужные значения и будет вам счастье.

Для каждого режима вроде свой SPSR, куда копируется CPSR... или это только в ARM7?

Не путайте архитектуру и ядро. ARM7 -- это семейство ядер, так же как и ARM9, ARM11, Cortex-A и т.д. А поведение процессора определяется спецификацией на архитектуру, а не на ядро (можно сказать, что архитектура -- это что должно делаться процессором, а ядро -- это как оно делается в конкретной реализации процессора).

Все версии архитектуры ARM, кроме M-профиля (ARMv6-M и ARMv7-M, ядра серии Cortex-M) ведут себя в общем и целом одинаково, просто каждая последующая версия архитектуры добавляет новые вещи. Ядро ARM7TDMI -- это версия ARMv4T, ARM926 -- это ARMv5TEJ (но ARM920T -- это ARMv4T, так что по цифрам в номере ядра судить об архитектуре нельзя). Все они обрабатывают прерывания абсолютно одинаково. Более того, даже суперсовременные процессоры с ядрами Cortex-A обрабатывают прерывания тем же самым способом, хотя там довольно много разных дополнений и расширений.

Собственно я в своей операционке mkernel так и реализовал вложенные прерывания на ARM7. Только нужно не забывать предварительно сохранять r0-r3, r12, lr, spsr. Иначе мы никогда не вернемся в точку возвращения. По ссылке ниже - полные исходники на реализацию вложенных прерываний и FIQ.

https://github.com/alexeyk13/mkernel/tree/master/arch/arm7

Получается что FIQ вам не нужен. Зачем тогда его используете? Сделайте все прерывания через IRQ.
И обнулять в обработчике ничего не нужно. Почитайте мануал на ядро про режимы процессора. Найдите где у вас в начале программы выставляются дефолтные значения для флагов CPSR для режимов FIQ и IRQ и выставьте их там.

У себя я сначала тоже было сделал поддержку и FIQ, и IRQ, а потом понял, что на практике пользы от FIQ никакой, а лишний код и всё прочее требует. Поэтому и отказался от него. Ну а поскольку сам по себе из воздуха он не возникает, то и заботиться о его запрещении не требуется: можно считать, что его просто нет. (Правда, не исключаю, что в природе существуют микроконтроллеры, где на него что-нибудь завязано, но пока не встречался).

Не совсем так. Основной смысл FIQ - это быстрый вызов прерываний. Так как никаких pending битов в ARM7 нет, а на обработку nested interrupts нужно время, можно не уложиться во временные пределы. Плюсом у FIQ свой банк верхних регистров, поэтому не нужно сохранять контекст, а можно сразу приступать к обработке. Другое использование - если nested interrupts не реализованы (а кодить тут, если с приоритетами, сильно больше, чем просто подключить FIQ), чтобы не дожидаться завершения прерывания, можно использовать FIQ.

Да всё это понятно, но, если скорость обработки настолько критична, что считать приходится отдельные такты (а сохранение/загрузка регистров и тому подобные действия -- это именно несколько тактов), то следует подумать о переходе на более мощный контроллер или, например, использовать ПЛИС.

Дополнительный блок регистров, это лишь бонус. Если мы рассматриваем nested interrupts (для запрета вложенных прерываний необходимость FIQ и так очевидна, имхо), то, при достаточно разветвленной системе прерываний и наличии приоритетов, программная реализация NVIC - это не только упомянутый stacking/ustacking, но еще и очередь приоритетов, что всегда - компромисс между скоростью и возможностями. И уж точно не несколько тактов. В лучшем случае - несколько десятков тактов. Плюсом, любое менее приоритетное прерывание, хоть и не будет вытеснено, но может затормозить обработчик на время проверки приоритетов. Так что, в обоих случаях, быстрый FIQ может найти свое применение.