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.

[参考译文] MSP430FR5964:软件过载导致了 I2C 硬件延迟?

Guru**** 1828310 points
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/msp-low-power-microcontrollers-group/msp430/f/msp-low-power-microcontroller-forum/1420791/msp430fr5964-software-overload-causing-i2c-hardware-delays

器件型号:MSP430FR5964

工具与软件:

尊敬的所有人:

我正在从事一个项目、我们使用大部分可用的 USCI 模块、其中一些模块用于 UART、1个 SPI 和3个 I2C。 I2C 模块是 ISR 优先级(UCB1-3)中的最后一个模块。 在 UCB3上、我们有时会收到不需要的停止条件中断、这会破坏整个通信。 代码基本上在一段(随机的)时间内有效、然后给出这个停止条件中断(并非由软件启动)、这会扰乱整个通信。 这种情况似乎来自时序问题(例如、SCL 和 SDA 之间的时序有时太少、并形成一个 FAL STP)。

我的问题是:由于软件过载处理器、硬件 USCI 模块(在本例中为 UCB3)是否可能有一些滞后或延迟(例如在传输我想要发送的地址和字节期间)、或者如果 e.g.an 中断被触发但没有被及时处理、这只有所有者?  

谢谢!

Richard

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    据我所知、eUSCI 的运行是独立于 CPU 以及彼此独立的。 I2C 模式提供一定程度的流控制(通过时钟延展)。 在这些情况下、需要 CPU 干预、但一般情况下会自行进行。

    我不确定"不必要的"停止中断是什么意思。 如果您在 IE 寄存器中未启用停止中断、则该中断不会在 IV 寄存器中出现。 (它仍将出现在 IFG 寄存器中。)

    因为 STPIFG 的优先级(在 IV 寄存器中)高于 RXIFG、所以在主-接收模式中会发生竞争。 如果在停止完成之前没有处理最后一个字节的 RXIFG、则会首先显示 STPIFG。 时间范围是单个 SCL 周期、因此这很可能、尤其是在 CPU 繁忙时。 如果你认为这种情况正在发生、你可以考虑(a)根本不使用 STPIFG (b)直接检查 IFG 位[强制实施你自己的优先级方案](c)使用 DMA。