ARM Cortex-M4 Приоритеты прерываний

Ответ на ваш вопрос зависит от того, как он блокирует передачу, как сказал @Notlikethat.

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

Если ваш драйвер SPI управляется прерываниями, он не будет работать. Поскольку вы выполняете прерывание с приоритетом 2 (GPIO), прерывание с приоритетом 3 (SPI) не будет выполняться, пока прерывание GPIO не завершится. В зависимости от того, как написан ваш драйвер SPI, это может привести к полному зависанию вашей системы или тайм-ауту.

Если ваш драйвер SPI управляется DMA, то ответ не так ясен и зависит от того, как работает драйвер. В этом случае возможно, что ваша транзакция завершится, но если функция заблокировала ожидание прерывания DMA, она может никогда не поступить в зависимости от ее приоритета.

В любом из вышеперечисленных случаев обычно считается плохой идеей делать что-то подобное внутри прерывания. Если у вас есть RTOS, вы можете использовать задачу с высоким приоритетом, ожидающую на семафоре выполнения транзакции SPI, или, если ОС поддерживает это, использовать отложенную обработку прерывания. Если вы не работаете с RTOS, я бы подумал, есть ли способ сигнализировать о прерывании с более низким приоритетом (т.е. использовать PendSV с самым низким приоритетом) или контролировать флаг внутри основного процесса. Используя прерывание с более низким приоритетом, вы все равно можете вытеснить основной процесс (если это необходимо), но все ваши другие прерывания могут продолжать выполняться. Если вы можете отслеживать флаг в своем основном процессе, это также позволит продолжать прерывания, но если вы ограничены во времени, это может быть невозможно (опять же, в зависимости от того, как структурировано ваше приложение).