简体繁体 English

ARM Cortex-M4中断优先级

[英]ARM Cortex-M4 Interrupt priorities

原文 2016-09-15 23:24:44 1 1 arm/ spi/ cortex-m/ irq

I'm using an ARM Cortex M4 MCU. 我正在使用ARM Cortex M4 MCU。 If I have an interrupt handler for a GPIO at priority 2 and an SPI driver at priority 3 (ie, lower priority than the GPIO's), and I call a (blocking) SPI read from within the GPIO's interrupt handler, will the SPI function work? 如果我有一个优先级为2的GPIO中断处理程序，以及优先级为3的SPI驱动程序（即，优先级低于GPIO的中断处理程序），并且我从GPIO的中断处理程序中调用了（阻塞）SPI读取，则SPI功能将起作用？

1 个解决方案

The answer to your question depends on how it is blocking to handle the transfer, as @Notlikethat said. 问题的答案取决于@Notlikethat所说的如何阻止传输。

If your SPI driver is a polling driver, then it will most likely work. 如果您的SPI驱动程序是轮询驱动程序，则很可能会起作用。 In this case, your GPIO interrupt would spin on flags within the SPI peripheral, waiting for each part of the transfer to complete. 在这种情况下，您的GPIO中断将在SPI外设中打开标志，等待传输的每个部分完成。

If your SPI driver is interrupt driven, then it will not work. 如果您的SPI驱动程序是中断驱动的，那么它将无法工作。 Since you are executing a priority 2 interrupt (GPIO), the priority 3 interrupt (SPI) will not execute until the GPIO interrupt finishes. 由于您正在执行优先级2中断（GPIO），因此在GPIO中断完成之前，不会执行优先级3中断（SPI）。 Depending on how your SPI driver is written, this may entirely hang your system, or it may result in a timeout. 根据SPI驱动程序的编写方式，这可能会使系统完全挂起，或者可能导致超时。

If your SPI driver is DMA driven, then the answer is not so clear and depends on how the driver works. 如果您的SPI驱动程序是DMA驱动的，那么答案就不太清楚，取决于驱动程序的工作方式。 It is possible in this case, that your transaction would complete, but if the function has blocked waiting for a DMA interrupt, it may never arrive depending on its priority. 在这种情况下，您的事务可能会完成，但是如果该函数阻塞了等待DMA中断的时间，则它可能永远无法到达，具体取决于它的优先级。

In any of the above cases, it would generally be considered not a good idea to do something like that inside of an interrupt. 在上述任何一种情况下，通常在中断内部执行类似操作都不是一个好主意。 If you have an RTOS, you could use a high priority task that is waiting on a semaphore to execute the SPI transaction, or if the OS supports it, used deferred interrupt processing. 如果您有RTOS，则可以使用等待信号量的高优先级任务来执行SPI事务，或者，如果OS支持，则使用延迟中断处理。 If you aren't running with an RTOS, I would consider if there is a way you can signal a lower priority interrupt (ie use PendSV at the lowest priority) or monitor a flag from within the main process. 如果您不使用RTOS运行，我会考虑是否有一种方法可以发信号通知优先级较低的中断（即以最低优先级使用PendSV）或从主进程中监视标志。 Using a lower priority interrupt, you can still preempt the main process (if that's what is needed), but all your other interrupts can continue executing. 使用较低优先级的中断，您仍然可以抢占主进程（如果需要的话），但是所有其他中断都可以继续执行。 If you can monitor a flag in your main process, then that would also allow your interrupts to continue, but if you are time constrained, this may not be as possible (again, depending on how your application is structured) 如果您可以在主进程中监视标志，那么这也将允许您的中断继续进行，但是如果您受时间限制，则可能无法这样做（再次取决于应用程序的结构）