Всем привет!

Есть регистр Application Interrupt and Reset Control Register, в котором задается поле PRIGROUP, то есть разбитие прерываний на группы и подгруппы по приоритетам.
Вопрос нафига оно надо, чисто для удобства?

допустим у нас 16 групп и 16 подгрупп, прерывание из 5 группы, 0 уровня, 5.0 (значение в поле приоритета 0x50 = 80) имеет приоритет выше прерывания 6.0 (значение в поле приоритета 0x60 = 96). Но так и прерывание 80 имеет приоритет выше 96.

То есть разбитие на группы получается чисто для человека, удобства чтения, что ли...

Более того это поле вынесено в другие регистра, а не в группу NVIC, который вроде как является частью всех кортексов. И как я понимаю его вообще не интересуют группы, ему нужен конечный номер, да еще с числом используемых им в реализации бит или же я ошибаюсь?
в NVIC прерывание с высшим приоритетом всегда прервет текущее, а с тем же или более низким будет ждать окончание текущего, не зависимо от группы, или это не так? И прерываться будут только подгруппы? А внутри одной группы прерывания не будут друг друга прерывать?

Именно так

А внутри группы будет запускаться первым прерывание с большим приоритетом?
А прерывания с одним приоритетом группы и подгруппы, первым запускается с меньшим номером по счету?
Так?

К примеру, у STM32 есть только 4 бита для приоритета - не разгуляешься. Так что 16 групп и 16 подгрупп - это вы оптимистично заявили. Поэтому возможность поделить эти биты на группы и подгруппы нужным образом может быть вполне полезной.


А мануал на что? Лень пару предложений почитать?

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

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

у вас талант находить ответы на их сайте.
LPC это все вообще в мануал к процу пишут. STM просто упоминает, после этого я уже понял надо искать на сайте ARM. Но я честно через поиск на сайте не фига не могу найти, я реально чаще нахожу ответы через гугл, который дает ссылку на их сайт. А через их окошко прям беда....

хотя вот сейчас думаю что дело в том что лезу через arm.com, а надо через infocentr сразу, наверное...

Спасибо за потраченное время)

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



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

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


буду через инфоцентр лазить, уже понял, спасибо...

Там можно скачать документ на конкретное ядро в виде обычного pdf.

я знаю, спасибо.
Просто искать на arm.com и infocetr.arm.com по результатам, получается по разному, не понятно почему...

Мои 5 копеек: во всех моих программах я вызываю:


и получаю 16 уровней приоритетов 16-ти подгрупп.
При инициализации прерывания периферии я подгруппы не использую (всегда 0), только лишь раскидываю периферии по 16-ти приоритетам, чего, по моему мнению, более чем достаточно. По опыту хватило бы и 8-ми.

Внутри группы при одновременном поступлении сигналов прерывания, вызовется то, что с более высоким SUB приоритетом.
Собственно редкий случай, на это в обычном приложении можно и не обращать внимания. Особенно когда у вас есть сами приоритеты.
Возможно в какой-то задаче это и может быть важным. Не знаю



Хм. Уважаю Ваш опыт.
По моему опыту хватило бы и двух-трёх.

Одновременно прерывания наступить не могут, поэтому эту фразу нужно понимать так:
во время выполнения более приоритетного прерывания пришли запросы от нескольких менее приоритетных прерываний.


Никто не запрещает взводить pending-битики в прерывании.
Установив несколько таких битиков в более приоритетном прерывании для нескольких менее приоритетных, но равных по приоритету прерываний,
за счет sub-приоритетов можно задать рекомендуемый порядок выполнения.
Например.

Кто сказал, что вытесняющие прерывания это однозначно хорошо? Раньше не работал с вытеснением - не знал головной боли с синхронизацией.

Какой МК, если не секрет?
Я как бы намекаю, что, например, в STM32 всего 4 бита приоритета, а в LPC - вообще 3. Поэтому это ваше щедрое деление 8 бит на 4 и 4 - это возможно только в очень богатом МК.


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

Обсуждение ведется в части целесообразности sub-приоритетов.
Есть мнение, что это лишнее. Мол, отработать в природе они не смогут, т.к. событие очень редкое - должны придти запросы в пределах одного такта.
Я же привел пример, как повысить вероятность "работы" sub-приоритетов.

Вот скажите, если приоритетное прерывание работает (PRIO-1), возникает запрос на прерывание от менее приоритетного (PRIO-2.2), а затем
через 1000 тактов возникает запрос на прерывание от другого источника с таким же низким приоритетом (PRIO-2.1).
Можно считать, что нет разницы когда возникли несколько менее приоритетных прерываний, т.к. анализировать NVIC их будет в момент окончания
более приоритетного прерывания? Кста, победит PRIO-2.1 именно за счет sub-приоритета.

Это в каком LPC, интересно? По-крайней мере для LPC17xx вроде 5 бит для задания приоритета. Параграф 34.4.2.7 UM:
The IPR0-IPR27 registers provide a 5-bit priority field for each interrupt.


Зависит от архитектуры ПО. Может быть и не редко. Не обязательно даже чтобы запросы поступили в одном такте. Достаточно чтобы они поступили во время обслуживания более приоритетного прерывания.
Тогда, после его завершения, и будет использована подгруппа.
Хотя я тоже подгруппы никогда не использую: всегда выставляю PRIGROUP так, чтобы получить макс. кол-во групп.