您好,
实现了一个 ISR 例程并已将优先级设置为高电平(0x00)。
想知道的... 完成 ISR 是否有任何特定的时间限制或约束?
如果是,如果 ISR 需要更长的时间,会发生什么情况?
我在 ISR 中执行了一段代码来驱动 GPIO 并访问 I2C 以配置另一个从器件。
驱动 GPIO 是正确的,但没有发生与 I2C 相关的事务,并且单元将重新启动。
您能不能帮助您了解重新启动的可能原因、以及是否有任何方法可以避免重新启动。
谢谢,
Rohith。
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好,
实现了一个 ISR 例程并已将优先级设置为高电平(0x00)。
想知道的... 完成 ISR 是否有任何特定的时间限制或约束?
如果是,如果 ISR 需要更长的时间,会发生什么情况?
我在 ISR 中执行了一段代码来驱动 GPIO 并访问 I2C 以配置另一个从器件。
驱动 GPIO 是正确的,但没有发生与 I2C 相关的事务,并且单元将重新启动。
您能不能帮助您了解重新启动的可能原因、以及是否有任何方法可以避免重新启动。
谢谢,
Rohith。
技术答案是否定的、但实际上、中断例程应该非常短、因为它们通常会阻止 CPU 处理其他中断。 (此器件确实支持嵌套中断、但这是一个更高级的主题。) 您提到代码正在执行重新引导。 这是否意味着它正在执行复位? 数据表中列出了复位源。 从您的描述中、它听起来像是启用了看门狗的代码、而您的长中断例程会使 CPU 无法馈送看门狗。 正确的解决方案是使中断例程保持较短的时间。 在中断例程中等待 I2C 传输完成是一个坏主意。 根据您在中断例程中执行的操作、您可以在中断例程中设置一个标志、然后在主循环中检查该标志。 然后、您在主循环中执行所有耗时的工作。 或者、如果情况是在 I2C 上发送或接收多个字节、则使用具有静态变量的 I2C 中断例程来跟踪状态。