Easyelectronics.ru

Насколько я смог выяснить, NVIC работает примерно по таким правилам:

* Если выполняется ISR некого прерывания с номером IRQn и в этот момент приходит прерывание с более низким IRQn (более приоритетное), выполнение текущего ISR откладывается и управление передается ISR более приоритетного прерывания.
* Если приходит прерывание с таким же или более низким приоритетом, то его выполнение приостанавливается до завершения выполняемого сейчас ISR
* Плюс к этому пользователь может временно "маскировать" прерывания

Но вот чего я не смог выяснить - это как данный механизм работает в граничном случае. Если генерируется прямо очень много прерываний, не может же МК отложить выполнение бесконечного числа прерываний. Отсюда вопрос - чем ограничивается число отложенных прерываний? Что происходит в момент, когда этот лимит становится исчерпан?

У NVIC есть множество портов "входа" (прерывания). На _каждом_ порте задаются условия того, что прерывание (толчок NVIC) будет выполнено. Эти условия - разрешено и не замаскировано. Итак, аппаратура дернула свой порт, на нем взвелся флажок "ща будет interrupt". Этот сигнал (а флажок есть сигнал) будет висеть _вечно_, пока прерывание не будет сброшено. Все эти сигналы, через страшного паука (который называется приоритерный арбитраж) идут на само ядро NVIC. Первый же сигнал, который прошел через арбитраж, попадает в NVIC и далее оно обрабатывается.
После выхода из обработчика прерывания и перед восстановлением контекста, NVIC спрашивает - есть ли еще что у арбитража? Если есть, то понеслось еще цикл. Иначе - куча pop'oв и возврат в основной тред.

Любое прерывание может быть отложено на столько на сколько нужно, пока не дойдет его очередь и в самом конце возврат в основную программу. Если речь идет не о кортексах М0, то переход в прерывание занимает 12 циклов, во вложенное 6 циклов, т.к. нет необходимости сохранять контекст прерванной программы пользователя. Благодаря концепции построения NVIC обработчик выглядит как обычная функция и компилятор физически не понимает где у вас в программе обработчик, а где обычная функция. Также любое прерывание можно вызвать программным способом и ограничить приоритет на определенном уровне, т.е. например запретить все прерывания с приоритетом ниже 4.

На этот вопрос есть хороший ответ в Programming manual, разделы Exception entry and return, Exception priorities, Interrupt priority grouping. Прочитав их, вы узнаете, как выполняется вход и выход из прервания, что такое отложенное прерывание и что такое приоритеты и группы приоритетов.

Число отложенных прерываний ограничивается только числом векторов прерываний. Они могут хоть все стоять в ожидании, если позволяют их приоритеты.
Каждый раз, когда возникает запрос прерывания при уже выполняющемся (активном) прерывании (и при условии, что группа приоритета нового прерывания не выше приоритета активного прерывания!), новое прерывание ставится в "ожидающее" (pending) с установкой соответствующего бита в регистрах отложенных прерываний. Уже выполняющееся (активное) прерывание может выполняться сколько угодно, это определено кодом обработчика, а значит все новые прерывания с равным или более низким приоритетом будут ждать так же сколь угодно долго. Затем, когда все-таки код обработчика завершится, ожидающие (pending) запросы начнут вызываться в соответствии с их группой приоритета, номером приоритета в группе, номером вектора прерывания.
Отдельный момент касается групп приоритетов прерываний. Начиная с Cortex M3, имеются задаваемые пользователем группы приоритетов. Там же, в программинг мануале описано, с помощью чего задается разбиение на группы. Так вот, право вытеснять активное прерывание имеет то вновь поступившее прерывание, которое стоит в группе с приоритетом выше. Прерывания, стоящие в одной группе, вытеснять друг друга не могут, внутри группы определяется только очередность вызова в случае постановки в отложенные прерывания. По умолчанию группы приоритетов не используются.

Да вот фига.
Одно прерывание может быть задержано на исполнение бесконечно долго.
Два и более откладывать уже нельзя. Их нужно сбрасывать сразу, и записывать событие в очередь. Когда придёт время обработки, принудительно программно вызывать прерывания в порядке их приоритета. Иначе будет сбой стека.
Проще всего разрешать/запрещать глобально.
А верное решение - позволить прерываниям отрабатывать свой код в момент срабатывания, без запретов и логов. Для этого есть аппаратная поддержка - которая никогда не сбоит.

Задержанный (отложенный, замаскированный) флаг прерывания NVIC никакого стека не потребляет.
Как-бы, совсем мимо.

Это вот вам - фига :)
Теоретически можно задержать хоть пийсят прерываний, они на стек не влияют, а все ставятся в состояние ожидания. Практически вы конечно опоздаете с реакцией на прерывание, но стек таким способом вы не поломаете.
Программно ничего тоже не надо вызывать, они там сами разрулятся и порешают всё.
Зато вот запрет/разрешение глобально - ...хм... а зачем он, если вы не пишите критеческие секции, которые не должны преываться? Глобольным запретом вы можете сбить системный таймер, а значит, поломаете отсчет интервалов времени на нем.
Последняя ваша строчка как-то совсем уж непонятна и противоречит предыдущему предложению.

Всех благодарю за ответы! Хотел бы прояснить последний момент.


Если отложенные прерывания не складываются в какой-то стек или очередь, верно ли я понимаю, что они складываются в битовую маску? Означает ли это что если будет отложено два одинаковых прерывания (например, два нажатия одной и той же кнопки), то они схлопнутся в одно прерывание?

Это как в анекдоте про палача и острый топор:
-А теперь кивни.

Задержка обработки прерываний слабее приоритета.
Это означает что ручной вызов прерываний с нарушением приоритета - автоматически гробит стек. А разбираться стем кого пускать первым на обработку - та ещё морока.
Особый прикол когда во время вытеснения и последующей задержки слабого прерывания - прилетает пара старших по уровню.

Я предлагаю не снашать мозг, а использовать аппаратное решение с минимальным кодом (установка флага). Остальное делать в потоке (уже если так сильно хочется).

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



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

А в этом случае теряется весь смысл прерываний как таковых. Ведь у каждого модуля, генерирующего запросы прерывания, и без того есть собственный флаг, его то и можно проверять в основном цикле.
Если в обработчике прерывания вы лишь выставляете программный флаг, то этим вы откладываете реакцию на прерывание на некоторое время, зависящее от количества написанного в основном цикле while(1).


Да, верно. Выше я показал картинку как раз с такой "битовой маской". Ею заведуют регистры Interrupt set-pending registers (NVIC_ISPRx), в них каждый бит соотвествует порядковому номеру перывания. Порядковые номера можно посмотреть в том же программинг мануале или в файле заголовочника МК. На картинке - ожидающие прерывания с номерами 25, 27-30, 35, 36, соответствующие TIM1_UP_TIM16_IRQn, TIM1_CC_IRQn, TIM2_IRQn - TIM4_IRQn, SPI1_IRQn, SPI2_IRQn.


Да. NVIC не имеет очереди одного и того же прерывания. Одно и тоже прерывание фиксируется только один раз. И если откладывать его обработку, то следующий запрос этого же прерывания будет пропущен.
Это вот уже практическая часть, из которой понятно, что надолго задерживать обработку отложенных прерываний - нехорошо, потому что можно пропустить следующий по времени запрос от этого же источника.

BusMaster, большое спасибо за объяснение!

Мне, пожалуй, остался не до конца ясен только один момент. Когда ISR некого прерывания вытесняется ISR пришедшего более приоритетного прерывания, где сохраняется контекст вытесненного ISR? Если на стеке, то верно ли мое понимание, что в пределе стек теоретически можно переполнить, например, если ISR кушают много стека под локальные переменные?

Вы используете локальные переменные в ISR? ... тогда мы идем к вам.(с)BUGs

Со стеком так:
1. если мы в PSP (режим потока Thread), то первое прерывание контекст сохраняет в PSP, остальные вложенные уже в MSP, т.к. все прерывания выполняються в режиме обработчика (Handler).
2. если мы в MSP, то в тот стек все и сохраняеться.
переполнить стек всегда можно прерывание потребляет (сохр.контекст) 64 байта стека, это без учета регистров FPU. т.е. это минимум.

AVI-crak, что-то вы перемудлили это точно в своей ОС.

u37 В чем у вас проблема с локальными переменными в прерываниях? ну будут они лежать себе в стеке да и все. Вообще не вижу проблем.

В целом вопросов очень много всегда, вот например мало кто задумывался что при переносе таблицы векторов в ОЗУ время вхождения в прерывание увеличиваеться (>12 тактов), т.к. нет возможности одновременно сохранять контекст и делать выборку вектора.

Конечно на разных.
У вас даже фотка есть где прерывания запрещены глобально. Глобальный запрет и отложенное выполнение нескольких прерываний (из всех имеющихся) - это не одно и то-же. Ближайший аналог ситуации: пробка перед светофором, и "товарищи" обгоняющие общую очередь по грунтовке.
Именно в этом смысл позднего выполнения прерывания...
У вас при глобальном разрешении прерываний - оные ломануться выполняться в порядке приоритета, и всё будет хорошо - кроме потери смысла общего алгоритма программы.

Загляни в другие ос, и ужаснись.
Сделай своё, и хвали до конца жизни.

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

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

Где они там запрещены?? Эти вектора просто не были включены, а инструкции глобального запрещения прерываний (CPSID) не было.
Послушайте, ведь вы из-за того, что не до конца разобрались, противоречите сами себе.


ПОЧЕМУУУ????? Почему теряется смысл? У вас, кмк, проблемы с этим самым алгоритмом. Отложенная обработка прерываний? Вот где потеря смысла прерываний в принципе. То есть, вы ведете сейчас речь о таком алгоритме:

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

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

У операционки отложенная обработка прерываний связана с самим понятием операционки. Однако, даже в операционке есть возможность обрабатывать прерывания вне действия API операционки, ни что этому не мешает.

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

Это и есть "строго по одному". В порядке приоритета.

Эта фраза не несет в себе информацию о том что прерывания вложенные и сам процесс вложенности влечет за собой потребление стека, так что стек все-таки расходуеться, но только если приоритет нового прерывания выше текущего это + 8 слов и лок.переменные обработчиков для каждого вложения.

Купите мешок цемента.

Может быть, немного понятней будет алгоритм обработки прерываний процессором:



В NVIC для всех 100500 источников прерываний есть приоритеты, оно выбирает максимальный активный источник (с учетом групп/подрупп) и выставляет его номер в процессор как IRQ#
Чтобы прерывание снялось надо скомандовать периферийному блоку снять его или замаскировать в NVIC, иначе после выхода из прерывания, когда ISR_NUMBER станет меньше IRQ#, вы опять войдете в это же прерывание.