Можно ли запретить NVIC прерывания ниже 10-го уровня? Опции

[igorle]

Я считал, что эту задачу решу за полчаса, но чем больше изучаю - тем больше запутываюсь.
Процессор STM32F103
Работаю с UART, SPI и USB
В некоторый момент мне надо запретить прерывания от USB.

Можно решить задачу в лоб - в нужный момент запретить два прерывания

Код

NVIC_DisableIRQ(USB_LP_CAN1_RX0_IRQn);
NVIC_DisableIRQ(USBWakeUp_IRQn);

А потом аналогично разрешить. Но это пОшло.
NVIC позволяет дать каждому прерыванию свой приоритет. Я полагал, что после этого можно, например, маскировать (запрещать) все прерывания ниже определенного приоритета. Но сегодня из документации понял, что приоритет дает только порядок обработки прерываний. А запретить можно или все (__disable_irq()), или одно конкретное прерывание(NVIC_DisableIRQ(irqn)).

Можно ли запрещать прерывания ниже определенного приоритета?

И второе. NVIC_SetPriorityGrouping(). Читаю описание хоть на английском, хоть на русском. Понимаю каждое слово, но не понимаю смысла группирования. Может кто-то свою трактовку одним-двумя предложениями дать?

[SSerge]

Можно ли запрещать прерывания ниже определенного приоритета?

В файле core_cmFunc.h есть функция
__set_BASEPRI(uint32_t basePri)

В двух словах,
все запросы прерываний приходят на приоритетный шифратор, он выбирает из них самый приоритетный,
им будет тот, у кого выше приоритет (меньше число в регистре NVIC_IPRx или SCB_SHPRx), а при равенстве - тот у кого меньше номер в таблице векторов.
Далее приоритет этого запроса сравнивается с приоритетом выполняющегося сейчас кода.
Для "просто программы" это содержимое регистра BASEPRI, если приоритет запроса выше - произойдёт прерывание.

Если процессор уже исполняет обработчик прерывания, то приоритет текущего обработчика сравнивается с приоритетом нового запроса. Только в этот момент имеет значение вся эта сложность с группами и суб-приоритетами.
Прервать обработчик прерывания сможет только запрос из более приоритетной группы.

Попробую сочинить пример:
после
NVIC_SetPriorityGrouping( 5 );
__set_BASEPRI(0xA0);
получаем следующую ситуацию:
есть 4 группы приоритетов: 0..3, 4..7, 8..11 и 12..15, прервать исполнение программы могут только запросы с приоритетом 9 и выше.

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

[igorle]

Спасибо огромное. На практике пока ваш ответ не проверил, но туман начал рассеиваться. И благодаря новым ключевым словам нашел тему, где этот вопрос уже обсуждался. Вот здесь - NVIC - Как заблокировать все IRQ с приоритетом ниже нужного

[igorle]

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

Мне такое поведение представляется очень нелогичным. Таймер должен быть наиболее приоритетным прерыванием. Иначе часы будут сильно убегать. Я теперь, после вызова SysTick_Config() сразу ставлю NVIC_SetPriority (SysTick_IRQn, 0). Но интересно бы понять, зачем основоположники так сделали. SysTick_Config - это даже не SPL - это функция CMSIS.