Arm NVIC中电流中断优先级的改变

我有一个难题。我正在使用的部件（NXP KL27，Cortex-M0+）在其I2C外围中有一个勘误表，因此在接收期间没有流量控制。因此，它需要是一个高优先级中断。我还使用了一个UART，由于它的异步性质，它的接收端没有流量控制。因此，它需要是一个高优先级中断

循环优先级

I2C中断需要比UART中断具有更高的优先级，否则输入字节在读取之前可能会在移位寄存器中被删除。它确实不应该以这种方式工作，但这是勘误表，因此它需要更高的优先级

UART中断需要比I2C中断具有更高的优先级，因为要结束I2C事务，驱动程序（来自NXP的KSDK）需要设置标志并等待状态位。在此等待期间，UART上的输入字符可能会溢出非FIFO移位寄存器

在试图解决UART的一个问题时，我发现了这种循环依赖性。最初的问题是UART接收中的字符消失，并设置了溢出标志。交换优先级时，UART坚如磐石，从未丢失过一个字符，但I2C事务最终因溢出而停止

可能的解决方案

我提出的解决方案包括动态更改中断优先级。I2C驱动程序在结束一个事务时没有接收，这意味着导致字节不受控制地流入的勘误表不是问题。在此期间，我想降级NVIC中的I2C中断优先级，以便UART能够优先于它，从而使UART愉快（并且不会丢失任何字符）

问题

我从ARM中找不到任何东西说明在执行中断时更改中断优先级是否会立即生效，或者当前中断的优先级是否在开始执行时被锁定。我希望有人能够从他们对架构的深入了解中，或者从他们的经验中，明确地知道改变优先级是否会立即生效

其他可能的解决方案

还有许多其他可能的解决方案以及它们不受欢迎的原因。重构I2C驱动程序以处理流程上下文中的循环，而不是中断上下文，这将是深入研究供应商代码并影响调用它的应用程序代码的一项重要工作。对这些外围设备中的任何一个使用DMA都会占用大量可用的DMA通道，并且会产生为每个事务设置DMA的开销（还影响调用驱动程序的应用程序代码）

我对其他解决方案持开放态度，但对于任何导致供应商代码发生重大更改的途径都犹豫不决

测试

---

我有一个实验的想法来测试NVIC在这方面是如何工作的，但我想我会先在这里检查一下。如果我进行了实验，我将发布一个带有结果的后续答案。

在体系结构上，这似乎是不可预测的（更改当前活动异常的优先级）。似乎没有实施更一致行为的逻辑（即，您关心的注册逻辑在M0/M0+中显然不存在）

这意味着，如果你测试你的变通方法的有效性，它可能会出现工作-在你的受限场景中，它可能是有效的。但是，不能保证相同的代码在M3上工作，也不能保证它在所有场景中都能可靠地工作（例如与调试的任何交互）。您甚至可能会观察到一些完全不可预测的角案例行为，但该区域受到限制

本规范第B1.5.4节将其规定为不可预测

对于v7-M（B1.5.4，异常优先级和抢占）

这个执行优先级的定义意味着异常处理程序 可以以高于的优先级执行 相应的例外情况。特别是，如果处理程序减少 其相应异常的优先级，则执行优先级下降 仅适用于优先级最高的抢占异常的优先级。 因此，永远不会降低当前异常的优先级 许可证：

• 用于抢占当前异常处理程序的抢占异常

• 反转抢占异常的优先级

---

v7-M特性阐明了一些复杂的场景，如果您试图利用不可预测的行为，必须避免这些场景，您已经确定这些行为对M0+部件是有用的

实验

今天，我编写了一个快速实验，在我的特殊变种大脑皮层M0+上测试这种行为。我将此作为一个无法接受的答案，我相信@Sean Houlihane的答案是最正确的（即，它是不可预测的）。在我使用它的过程中，我仍然想测试它的行为并在特定的情况下报告

实验在FRDM-KL43Z板上进行。它有一个红色LED、一个绿色LED和两个按钮。应用程序执行了一些GPIO设置和中断，然后在无限循环中运行

按钮1：按钮1的中断处理程序已初始化为中等优先级（0x80）。在按钮1的每个下降沿上，它将暂停中断。此中断将切换绿色LED的状态

按钮2：按钮2的中断处理程序已初始化为中等优先级（0x80），但将作为执行的一部分进行更改。按钮2中断处理程序将运行一个持续约8秒的循环（四个阶段的两个阶段），无限期重复。它将打开红色LED，并将其自身的优先级降低到低于按钮1的优先级。过了四秒钟，它就要爆炸了