[参考译文] RM48L950：SCI 对我的 RTI 计时器产生负面影响

除此之外、我为什么要使用通知例程来代替比较中断例程来处理回调？

void rtiCompare3中断(void)
｛
//用户代码开始(83)*/
//*用户代码结束*/

rtiREG1->INTFLAG = 8U；
rtiNotification (rtiNOTIFICATION_COMPARE3)；

//用户代码开始(84)*/

UnI_TIM_TIMERS_1sec_CBK ()；

//用户代码结束*
｝

这就是我刚才所说的、我从未见过有任何理由将回调函数移至通知例程。

您好 Jamie、

首先、我对延迟回答您的问题表示歉意。

关于您的问题、当您调整 SCI 中断优先级时、这是否可以解决 RTI 中断的延迟问题？ 也可以将 RTI 中断指定为 FIQ 与 SCI 中断的 IRQ。 FIQ 中断将优先于 IRQ。

关于回调函数的放置位置、我认为这是由您决定的。 因此、无论您的系统级需要什么、显示如何工作都是可以的。 在通知函数本身中保留回叫函数没有硬性要求。

更改 SCI 中断的优先级不会产生任何明显的差异。 我所做的是调整调试输出、以最大程度地减少传输的字节数、并将其移至1秒回调。 与第二个漂移相比、这改善了我在 ms 内看到的结果、但并未完全消除问题。

我将 RTI 作为 FIQ、看看它是否有用。 中断优先级(级别)的更改并未解决、这仍然让我感到惊讶。

您好 Jamie、

很抱歉后续行动晚了、但 FIQ 的变化是否显示有任何改进？ 我还感到惊讶的是，优先事项的变化没有显示出改善。 您是否允许在应用程序中使用嵌套中断？

你好、Chuck、

我查看了 FIQ、并了解到建议使用汇编器来实现这些中断、我还认为我在中断例程中具有的逻辑也许是我在尝试之前可以进一步优化的东西。 总之、不是、我没有尝试 FIQ、因为我认为这对我来说现在不会是永久性修复。

优先级的变化没有帮助使我感到困惑、我真的需要在这上面放置一个逻辑分析器、以便清楚地了解我们看到的延迟。 现在、我无法投入时间来解决这个问题。

您能不能评论嵌套中断的允许-这是我应该专门设置的东西、还是您提到一个较低优先级中断中的数据在较高优先级中断中被修改的可能副作用-以及可能产生的负面影响 具体取决于应用。

谢谢

Jamie

Jamie、

如果您不使用嵌套中断、我的问题与它们更相关。 即、如果 SCI 中断正在消耗所有可用的 CPU 资源、RTI 中断可能只能定期获得服务、这将影响其有效性、即使 SCI 的优先级较低。
如果您有兴趣、请访问以下链接、获取有关 Hercules 的嵌套中断用法的应用手册： www.ti.com/.../spna219.pdf