[参考译文] SPI 主器件发送了命令、未收到响应。

从器件需要一些时间来处理命令字节并将其响应放入 TXBUF。 必须在主器件开始再次发送时钟之前完成这一绝对操作。 因此、您必须找出最坏情况下的延迟、并让主代码至少推迟这么长时间。

您好、David：

但是、当我在从器件上启用 GPIO 中断进行入侵检测（低电平有效引脚 P1.5、P1.6、P1.7）时、SPI 通信开始失败：主器件接收0x00而不是预期的数据。

我的目标是、每当从器件从主器件接收到 0xA5 命令时、它应该会更新 SPI 响应中的入侵状态。 在启用 GPIO 中断的情况下、似乎 SPI ISR 未正确执行、或者 TX 缓冲区未更新、这可能是由于中断处理冲突。

我观察到的情况：

• SPI 单独工作正常。

• GPIO 中断单独运行正常。

• 同时启用这两个0x00选项会导致 SPI 响应失败（返回）。

我怀疑这是因为 中断优先级或阻塞问题 、其中 GPIO 中断可能会抢占或干扰 SPI ISR。 我希望获得有关处理 MSP430FR2433 上 SPI + GPIO 中断的建议方法的指导、以便：

1. SPI 通信始终正常工作。

2. GPIO 中断会更新入侵状态、此状态反映在 SPI 响应中。

如果您对此场景提出任何最佳实践建议、将不胜感激。

提前感谢！

与对待中断一样、最佳实践是快速完成。

GIE 在进入 ISR 时被清除、因此如果您的 GPIO ISR 很慢、它会阻止 SPI 中断。 在任何情况下、都将增加响应命令更新 TXBUF 的最坏情况延迟。

更新：

我还尝试在 SPI 通信期间禁用 GPIO 中断（将 CS 置为有效并启动 SPI 传输、然后在之后重新启用 GPIO 中断）、但这没有解决问题。 0x00启用 GPIO 中断后、从器件仍返回到主器件。

似乎是这样 仅屏蔽 GPIO 中断是不够的 和问题可能与 MSP430 如何同时处理 SPI 和 GPIO 中断或 SPI 状态机与 GPIO ISR 的时序有关。

需要有关如何正确处理的指导 SPI + GPIO 中断 这样：

1. SPI 主从通信工作可靠。

2. GPIO 中断可以更新入侵状态。

感谢您发送编修。

我知道 ISR 执行时间很关键、因为在进入 ISR 时 GIE 被清除。 慢速 GPIO ISR 可以阻止 SPI ISR、从而增加更新 TXBUF 以响应主器件命令的最坏情况延迟。

在我的实现中、当 GPIO 中断被禁用时、SPI 主/从通信正常。 但是、当我启用 GPIO 中断进行入侵检测时、SPI 命令有时会返回 0x00。

我已经尝试通过仅设置标志并让主循环处理更新 SPI 发送缓冲区来尽可能减小 GPIO ISR、但我尚未实现一致的结果。

我怀疑 GPIO 事件和 SPI 主器件命令之间的时序仍会导致竞态条件。 有关确保即使在 GPIO 中断发生时也能可靠更新 SPI TXBUF 的任何建议、请参考这些建议。

您错过了编辑器的 Insert:代码功能、该功能保留了格式（使其更难阅读）、并将代码置于可滚动窗口中。

已更改为插入：代码特征

我看到的第一件事是、您没有按照建议的顺序初始化端口。 清除 LOCKLPM5 后使用中断配置处理。

在 ISR 中清除 RXIFG 是毫无意义的、因为读取 RXBUF 会自动执行该操作。 （读取 IV 寄存器也会读取。）

您的命令代码会令人困惑。 ISR 好像正在接收寄存器地址、但随后将其用作命令。

缺少用于为 SPI 配置引脚的代码。

感谢您提供更好的格式。 但您也更改了您发布的内容。 很多。 这些注释仅适用于从设备代码。

哦,这是主代码中的一个大问题:

    SLAVE_CS_OUT &= ~(SLAVE_CS_PIN);
    SendUCA1Data(TransmitRegAddr);

    __bis_SR_register(CPUOFF + GIE);        // Enter LPM0 w/interrupts enabled

    SLAVE_CS_OUT |= SLAVE_CS_PIN;

如果唯一可能导致 LPM 退出的因素是 SPI 中断、则此操作正常。 不是。

感谢您的反馈。  在实现主设备通信时、我提到了“ msp430fr243x_eusci_spi_standard_master.c“。

 我希望获得有关处理 MSP430FR2433 上 SPI + GPIO 中断的建议方法的指导、以便：

1. SPI 通信始终正常工作。

2. GPIO 中断会更新入侵状态、此状态反映在 SPI 响应中。

如果您对此场景提出任何最佳实践建议、将不胜感激。

我看不到从器件配置 SPI 引脚的位置。 我希望看到如下内容：

    P2SEL0 |= BIT4 | BIT5 | BIT6;     // P2.4/5/6 as SCK/SIMO/SOMI
    P2SEL1 &= ~(BIT4 | BIT5 | BIT6);
    P3SEL0 |= BIT1;                   // P3.1 as STE
    P3SEL1 &= ~BIT1;

初始化或在某个位置。

我按照前面的建议更新了 SPI 引脚配置：

执行此操作后，从器件现在正在响应 — 但主器件始终接收 0x00 而不是预期的状态字节。

让我感到困惑的是,当你去增加主时钟的麻烦时,你将奴隶保留在其默认（较慢）设置。

良好的观察—感谢您指出这一点。

最初、我专注于增加主时钟 (MCLK/SMCLK) 以实现更快的 SPI 传输、但我将从器件保持在其默认 DCO 设置。 经过进一步测试、我意识到这种不匹配会影响 SPI 时序一致性、尤其是在命令和数据阶段之间的同步方面。

现在、我更新了从器件的时钟配置以匹配主器件（使用 DCO = 16MHz、SMCLK = DCO/2 =<xmt-block1> 8MHz</xmt-block>）。 8MHz。 两侧都在一致的时钟域上运行、因此 SPI 时序更加稳定、数据传输更加可靠。