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.

[参考译文] CC2538:CPU 重负载对 SPI 速度的影响

Guru**** 2874300 points

Other Parts Discussed in Thread: CC2538

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

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/1624601/cc2538-cpu-heavy-load-effects-on-spi-speed

器件型号: CC2538

您好的团队、


我的客户想确认、当 CPU 处理重负载任务时、SPI 速度是否会受到影响?  
例如 SPI CLK 变得很慢或数据相对于 CLK 很晚。

似乎他们在自己的系统上发现了这种现象。

 

此致、

Kenley

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

    尊敬的 Kenley:

    这是我们 之前的 E2E 主题。  这是同一个工程吗?如果是、CC2538 仍然作为 SPI 从器件运行吗?  我预计 SPI CLK 速度不会受到影响、因为这应该由 摄像头主控器驱动、但当 CPU 过载时、SPI 吞吐量肯定会降低、以至于它无法向 SSI FIFO 重新填充客户可能认为“延迟“的更多数据。  它们能否提供 SPI CLK 减速或异步数据的逻辑分析仪或示波器屏幕截图?  他们可以考虑围绕 SPI 操作实施关键部分、但这会影响其他任务的处理时间、从而造成重负载。

    此致、
    Ryan

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

    您好、Ryan

    感谢您的支持。

    是的、这是同一个工程、CC2538 仍作为 SPI 从器件运行。

    他们通过 DMA.Communication 将数据打包到 TX-FFIFO 中、频率为 3MHz。

    ① 有时、传输按字节不同步。 可能的原因和对策是什么?

    ② 如果 CC2538 不与主时钟保持一致、RX-FIFO 可能会按位堆叠吗?
    如果是、是否有办法在不降低主时钟的情况下避免这种情况?

     

    此致、

    Kenley

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

    客户提供商是否可以提供有关问题的逻辑分析仪或示波器屏幕截图、或者至少可以进一步说明收到的内容与预期内容? 这是不同步的字节还是 single-bit、并且后续的字节会受到影响? 只有 RX 受到影响、但 TX 不受影响?  什么是故障率?它可以可靠地复制吗?  发生故障的时间与此时在应用程序/内核上运行的其他内容之间是否存在任何关联?

    客户可以尝试将其 SPI 操作打包在关键部分内、提高 SPI 任务的优先级或降低整体负载。  如果这些不适用、则客户可能需要考虑缓解措施、方法是捕捉问题并通过状态或 CRC 字节提醒 SPI 控制器以重新传输。

    此致、
    Ryan

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

    您好、Ryan

    感谢您的支持。

    让我尝试与客户沟通、为我们提供可供分析的数据。

    同时、客户想确认从模式时钟 SSI 的设置。

    之前您说过、“对于从模式、系统时钟或 PIOSC 必须至少比 SSIClk 快六倍。“

    但是、在查看 cc2538 驱动程序库用户指南 《CC2538 外设驱动程序库用户指南》(修订版 A)后、

    在从模式下、时钟速度应该是原来的 12 倍。

    ui32BitRate 参数定义 SSI 的位速率。 该比特率必须满足以下时钟比率标准:
    FSSI >= 2 μ s 比特率(主∗)
    FSSI >=∗μ s 比特率(从模式)
    其中、FSSI 是提供给 SSI 模块的时钟的频率。

    答:在没有驱动程序的情况下、是否需要使用 SSIConfigSetExpClk 来运行到 swru319c.pdf 上的 5.33MHz 限制、并且需要额外的手动寄存器调整?
    客户理解 CC2538 本身是理论上能够支持 5.33MHz 的 SPI 从器件。
    他们希望此时在 3MHz 进行通信、因此如果您需要进行其他设置、请告知 我们。

    B: 为什么两本手册的限制不同? 这两种材料之间的描述似乎相互矛盾、但客户想知道描述的原因和描述的意图。

    此致、

    Kenley

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

    尊敬的 Kenley:

    TRM 和 外设驱动程序库用户指南之间的这种差异可能是在物理器件外设寄存器级别测试的最大允许与软件库实现的开销之间的差异。  这不是我第一次回顾软件实现方案的最大速度略低于数据表或 TRM 中定义的速度。  CC2538 是一种旧器件、因此更难跟踪和查找现有的错误报告或票据。

    32/12 是 2.667MHz、非常接近他们当前使用的 3MHz。  如果他们在关键部分中包装了 SPI 接收操作、行为会得到改善或消失、可能基于 CS 引脚被驱动为有效状态的时间。  但是、这可能会为被阻止的任务引入错误。

    此致、
    Ryan

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

    您好、Ryan、

    故障率频率是 10,000 次中的 2-3 倍。

    除了 SPI 通信(具有 DMA)之外、无线电通信(具有 DMA)、GPIO、计时器中断和相关的应用活动也定期运行。
    它与 SPI 异步运行、尽管它是周期性的、因此我认为它可以同时运行。

    似乎这种情况不仅发生在 RX 上、也发生在 TX 上。 但对于 TX、发生这种情况的原因如下。

    从端与主器件交换以下三个帧
    1.主器件->从器件帧
    2.从器件->主器件帧
    3.从器件->主器件帧

    当以 1 接收帧时、由于噪声和误报、时钟会增加 1 位。
    在帧以 2 传输时、第一个字节为 (0x00) 空数据。
    在帧以 3 进行传输时、第一个字节是最后一个要在 2 中发送的数据。
    它被分开发送一个字节。

    提前感谢您。

    Kenley

    此致、

    Kenley

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

    您好、Ryan、

    根据您之前的反馈、客户还有其他问题。

    ① 电流设置是否存在操作 5.33MHz 上限所需的问题?

    • 数据长度 8 位 SPI 模式 3 (SPO、SPH = 1)
    • 通信频率:3MHz
    • 主器件的通信每 16 位采集一次数据
    • 用于 DMA 传输的 RAM 为 256 字节
    • DMA 传输模式为基本模式

    ② 如果出现 问题、他们应该怎么做?

    ③ 这次,他们想在 3MHz 进行沟通(细节是 2.857MHz )。 他们应将其设置为执行该操作的确切程度如何?

    ④ 请告知客户以 32MHz /12 运行时的预期限值。 (例如,正常运行的中断的数量)

    ⑤ 软件库加载导致 32MHz /6 到 32MHz /12 的主要原因是什么? 我认为该库具有相当于设置寄存器的处理负载。

    ⑥“BSY"登记“登记册的条件是什么? 设置 SSI 和 DMA 后似乎发出了 BSY 标志、即使 未配置 DR、启用了 DMA 传输并且实际上没有发送或接收数据也是如此? 客户希望使用 BSY 检查移位寄存器中是否仍有任何数据。  


    提前感谢您。

    Kenley

    此致、

    Kenley

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

    鉴于低故障率和行为的性质(丢失一整个字节)、我建议这个问题可能涉及重新填充 DMA 缓冲区。  DMA 缓冲区由应用重新填充、如果有正在进行的优先级更高的任务处理 、则可能会将重新填充操作延迟到来自 SPI 控制器的下一个字节传输请求之后、从而导致字节延迟。  这可以通过改用乒乓模式 DMA 来解决、该模式 用于支持进出外设的连续数据流。  您可以从 TRM 的第 10.3.6.4 节中找到更多信息

    基于我们之前的 E2E 主题、我相信客户对 SPI 寄存器有全面的了解。  如果发送 FIFO 不为空、则设置 BSY。

    此致、
    Ryan

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

    您好、Ryan

    以下是客户的反馈。

    您的意思是:

    1. DMA 传输正在进行中:一旦 DMA 发送 256 个字节、DMA 就会停止。

    DMA 停止:剩余字节被吸入移位寄存器时(FIFO 尚不为空,但停止重新填充)

    3、在 FIFO 耗尽之前、CPU 必须为下一次传输重新启动 DMA、或者在 FIFO 为空时、CPU 发送 0。 这将移动一个字节。

    客户想要确认这一点。

    1.他们要传输 DMA 的数据已在 RAM 中准备好、在传输 DMA 时、uDMAChannelTransferSet () 函数与 ui32TransferSize=256 一起使用(根据要传输的帧而更改为 16、8)。

    我们认识到不受软件中高优先级处理的影响(尽管没有任务,因为没有操作系统)。

    例如、如果他们使用 uDMAChannelTransferSet () 函数以 ui32TransferSize=8 发送 256 字节的帧数据、并以 for 循环等方式发送该数据、则他们理解、高优先级处理可能会中断延迟。

    如果有一个错误的识别点,这将是有益的,如果你能教我们。

    2.关于 BSY,客户希望确认。
    假设是、如果他们要发送到主时钟的数据稍后在没有单个字节的情况下传输到 TX-FFIFO、则后续字节会立即传输到移位寄存器 、因为它们使用 SSIFss、因此 SSI_SR 的 TFE 将不会为“0":“:传输 FIFO 不为空。

    客户理解是否正确?

    此致、

    Kenley

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

    我想客户已经理解我尝试解释有关 DMA 操作的内容。  使用乒乓模式代替基本模式再次有助于降低风险。

    如果我正确理解 SSI 模块方框图、TX FIFO 位于 SSIDR 和发送逻辑之间、数据在发送前会存储在 FIFO 中。  因此、使用单字节时、FIFO 在传输字节之前不会为空 (TFE:0)。

    19.4.2.1 发送 FIFO

    通用 TX FIFO 是一个 16 位宽、8 位置深的先入先出存储器缓冲区。 CPU 通过写入 SSI 数据 (SSI_DR) 寄存器(请参阅 SSI_DR)将数据写入 FIFO、数据存储在 FIFO 中、直到被传输逻辑读出。 当配置为主器件或从器件时、并行数据在串行转换之前写入 TX FIFO、并分别通过 SSITx 引脚传输到连接的从器件或主器件。 在从模式下、每次主器件启动事务时、SSI 都会发送数据。 如果 TX FIFO 为空且主器件启动、则从器件在发送 FIFO 中发送第八个最新值。 如果自使用 SYS_CTRL_RCGCSSI 寄存器中的 SSI 位启用了 SSI 模块时钟以来写入 TX FIFO 的值少于八个、则会发送 0。 注意确保根据需要在 FIFO 中保存有效数据。 SSI 可以配置为在 FIFO 为空时生成中断或 µDMA μ s 请求。

    此致、
    Ryan

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

    您好、Ryan

    客户表示未检查 SSI 发送/接收 FIFO 的状态、但客户表示有足够的空间来处理每个帧、因此客户表示 DMA 补充应该没有问题。

    帧发送和接收流程重复如下。

    1. 所有要发送的数据都设置为 RAM、RAM 所有用于接收的区域都清除为 0
    2. 按照发送和接收的顺序调用以下两个函数、并开始 DMA 传输(因为 DMA 在最后一次发送和接收时处于 StopMode)。  

      uDMAChannelTransferSet

      uDMAChannelEnable

    3. 在 DMA 传输后、TX-FIFO 应已满、因此您提到的以下事件不会发生。
      “如果自使用 SYS_CTRL_RCGCSSI 寄存器中的 SSI 位启用了 SSI 模块时钟以来写入 TX FIFO 的值少于八个、则会发送 0 “
    4. 允许主器件侧的 CLK 传输(通过将 READY 信号设置为高电平)
    5. DMA 发送完成中断、接收完成中断等待两个完成
    6. 禁用主器件侧的 CLK 传输(通过将 READY 信号设置为低电平)

    此致、

    Kenley

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

    您好、Ryan

    我来共享它们的配置。

    如果需要修改任何订单、请告知我们。

    初始化:

    订单 模式 配置
    1. SysCtrlPeripheralDisable SYS_CTRL_PERIPH_SSI0
    2. SysCtrlPeripheralReset SYS_CTRL_PERIPH_SSI0
    3. SysCtrlPeripheralEnable SYS_CTRL_PERIPH_SSI0
    4. GPIOPinTypeSSI GPIO 的基址(SCK 引脚| MOSI 引脚| MISO 引脚)
    5. IOCPadConfigSet GPIO 的基地址(SCK 引脚| MOSI 引脚)、IOC_OVERRIDE_PDE
    6. IOCPinConfigPeriphInput GPIO、SCK 引脚、IOC_CLK_SSIIN_SSI0 的基址
    7. IOCPinConfigPeriphOutput GPIO、MISO 引脚、IOC_MUX_OUT_SEL_SSI0_TXD 的基址
    8. IOCPinConfigPeriphInput GPIO、MOSI 引脚、IOC_SSIRXD_SSI0 的基址
    9. 可支持 0x40008000 (SSI_CR0)
    10. SSIClockSourceSet 0x40008000 (SSI_CR0)、SSI_CLOCK_PIOSC
    11. SSIConfigSetExpClk 0x40008000 (SSI_CR0)、SysCtrlIOClockGet ()、SSI_FRF_MOTO_MODE_3、SSI_MODE_SLAVE、SysCtrlClockGet ()/2、 8 位
    12 SSIIntRegister 0x40008000 (SSI_CR0)、指向函数的指针
    13 SSIDMA 使能 0x40008000 (SSI_CR0)、(SSI_DMA_RX | SSI_DMA_TX)
    14 SSIEnable 0x40008000 (SSI_CR0)
    15 uDMAChannelAssign UDMA_CH11_SSI0TX
    16 uDMAChannelAttributeDisable UDMA_CH11_SSI0TX、UDMA_ATTR_ALL
    17 uDMAChannelControlSet (UDMA_CH11_SSI0TX | UDMA_PRI_SELECT)、(UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE | UDMA_ARB_4)
    18 uDMAChannelAssign UDMA_CH10_SSI0RX
    19 uDMAChannelAttributeDisable UDMA_CH10_SSI0RX、UDMA_ATTR_ALL
    20 uDMAChannelControlSet (UDMA_CH10_SSI0RX | UDMA_PRI_SELECT)、(UDMA_SIZE_8 | UDMA_SRC_INC_8 | UDMA_DST_INC_NONE | UDMA_ARB_4)

    通过在帧通信之前和之后设置 GPIO、它会通知主器件 CLK 传输的许可/不批准、并控制来自主器件的 CLK 的时序。

    以下是执行发送/接收应用时的流程。

    订单 模式 配置
    1. uDMAChannelIsEnabled UDMA_CH11_SSI0TX
    2. uDMAChannelTransferSet (UDMA_CH11_SSI0TX | UDMA_PRI_SELECT)、UDMA_MODE_BASIC、TxDataRAM 的源地址、0x40008008 (SSI_DR)、16 或 256 或 8
    3. uDMAChannelEnable UDMA_CH11_SSI0TX
    4. uDMAChannelIsEnabled UDMA_CH10_SSI0RX
    5. uDMAChannelTransferSet (UDMA_CH10_SSI0RX | UDMA_PRI_SELECT)、UDMA_MODE_BASIC、0x40008008 (SSI_DR)、RxDataRAM 的源地址、16 或 256 或 8
    6. uDMAChannelEnable UDMA_CH10_SSI0RX

    CC2538 中未设置 SSIFss 的引脚(在系统启动时配置)。
    在此状态下、发送/接收在启用 SSI 后开始、SSI SR 进入 BSY、数据传输从 CLK 接收开始、因此表示为始终有效(低电平状态)。 客户表示他们不知道寄存器是否实际从空闲转换、因为当未设置 SSIFss 时没有描述。

    他们使用的模式如下:

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

    序列是否始终为 MOSI 16 字节、MOSI 256 字节(一个或多个)、MISO 8 字节?  该序列中的哪个位置 可能会发生故障的 RX FIFO 位?  我假设它可以在 MOSI 256 字节的中间、还是总是在其中一个进程的开始或结束?  TX FIFO 也有同样的问题。  他们是否有逻辑分析仪屏幕截图、说明 SPI 线路上发生故障的位置、对于相关字节是否有任何不符的地方?  他们是否考虑过使用突发模式、DMAUSEBURSTSET、并将源增量增加到 UDMA_SRC_INC_32  (UDMA_ARB_4 将变为 UDMA_ARB_1 )?  这似乎在 TRM 中得到支持、并将是一个有价值的数据点。

    此致、
    Ryan

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

    您好、Ryan

    是的 、序列始终为 MOSI 16 字节、MOSI 256 字节(一个或多个)、MISO 8 字节。
    有 3 个现象,它总是一个过程的开始或非常结束。

    1.不发送 256 字节帧中的最后一个字节  

    2.未以 256 字节发送的最后一个字节将在接下来的 8 字节帧中发送

    3. 如果接收 16 字节帧时由于噪音或误报导致时钟增加 1 位。 在 256 字节帧传输时、第一个字节为 (0x00) 空数据。 发送 8 字节帧时、第一个字节是要在 2 中发送的最后一个数据。 之后、它以偏移一个字节的形式传输。

    我要求提供逻辑分析仪波形、但尚未响应。

    请问使用突发模式 DMAUSEBURSTSET、并将源增量增加到 UDMA_SRC_INC_32  (UDMA_ARB_4 将变为 UDMA_ARB_1 ) 所遵循的机制是什么?

     

    此致、

    Kenley

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

    这是我上一封信中的一个澄清问题、我想这是一次、除非另有通知

    1、2 和 3 是否相互兼容?  与中一样、未发送的最后一个字节 (1) 始终是由时钟噪声引起的、导致第一个字节为空数据 (3)? 提供的所有示例都不会一开始显示字节错误、前提是时钟出现误报。

    我期望时钟增加 1 位会导致所有数据都发生位移、而不是整个 0x00 字节移位。  然而、观察到的行为更能说明主机提供的时钟问题、而不是 CC2538 上的 DMA/SPI 实现。  您提到在本例中、没有 CS 也会导致问题发生。  因此、建议对每个数据包进行帧起始 (SoF) 和循环冗余校验 (CRC)、以确认消息实际开始的时间并验证其内容。 如果字节错误在一开始或结束时发生、那么与中间缺少一个字节相比、似乎可以解决。  DMAUSEBURSTSET 注释涉及 DMA 传输的不同方法、如果错误在开始或结束时发生、这可能不起作用、具体取决于对行为的进一步分析。

    此致、
    Ryan

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

    您好、Ryan

    感谢您的支持。

    它们没有出现故障的屏幕截图。  

    此就绪信号为连接的黄色光、在许可计时与 摄像头侧发出 CLK 时间之间为 15.64μs。

    您是否认为这个时间足以通过 DMA 填充 FIFO?  

    此致、

    Kenley

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您认为现在有足够的时间通过 DMA 填充 FIFO 吗?  [/报价]

    这将取决于 SPI 任务的优先级、以及无线电、应用、其他外设等其他任务的现有使用情况  发送 READY 信号之前是否有人准备 RX DMA 缓冲器配置?

    此致、
    Ryan

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

    您好、Ryan

    感谢您的支持。

    明天我将与客户会面。

    在请求您的进一步支持之前、我需要确认和组织太多信息。

    此致、

    Kenley

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

    您好、Ryan

    让我重新安排我在今天的会议上收到的情况和资料。

    有关的现象。

    1.不发送 256 字节帧中的最后一个字节  

    2.未以 256 字节发送的最后一个字节将在接下来的 8 字节帧中发送

    3. 如果接收 16 字节帧时由于噪音或误报导致时钟增加 1 位。 在 256 字节帧传输时、第一个字节为 (0x00) 空数据。 发送 8 字节帧时、第一个字节是要在 2 中发送的最后一个数据。 之后、它以偏移一个字节的形式传输。

    →1 号和 2 号是相互兼容的。 因此、当出现 1 时、出现 2。

    首先、客户希望首先关注解决这种现象。  

    为实现这种现象、
    这意味着、 未在 256 字节帧中发送的最后一个字节仍应位于 TX-FIFO 或移位寄存器中、以便它们发送下一个 8 字节帧时、第一个字节将是前一帧中未发送的最后一个字节。

    你同意这一点吗?  

    这里是他们的问题。

    1.他们是否可以使用任何寄存器来检查 TX-FIFO 或移位寄存器中是否有任何数据?  

    2.他们是否可以使用任何可用的库来清除 TX-FIFO 或移位寄存器?

    3. TX-FFIFO 将数据发送到移位寄存器的触发条件是什么? 是从器件接收主时钟还是任何其他触发时?  
    如果您能分享背后的硬件逻辑、我们将不胜感激。
    它们只是要确保其余未发送的数据卡在 TX-FIFO 或移位寄存器中。

    如下所示、它们在发送主器件就绪符号以发送时钟之前对 DMA 重新填充。  
    为了防止出现这种现象 1 和 2、他们希望在发送 256 字节帧后清除 TX-FIFO 或移位寄存器、这样当它们启动 8 字节帧时、前一个帧不会影响数据。

    如果我误解或需要任何信息、请告诉我。  

     

    此致、

    Kenley

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

    我同意他们的理解。

    1.我们之前讨论了  SSI_SR 寄存器的 TFE 位、我认为它也适用于这种情况

    2.我没有看到任何用于清除 TX FIFO 的寄存器 SSI 寄存器。  您可以让主器件  通过时钟线请求额外的字节、并确定是否接收到任何额外的有效数据。

    3、我的可用内容来自 TRM:“在从模式下、SSI 在主器件每次启动事务时传输数据。 如果 TX FIFO 为空且主器件启动、则从器件在发送 FIFO 中发送第八个最新值。 如果自使用 SYS_CTRL_RCGCSSI 寄存器中的 SSI 位启用了 SSI 模块时钟以来写入 TX FIFO 的值少于八个、则会发送 0。 注意确保根据需要在 FIFO 中保存有效数据。 SSI 可配置为在 FIFO 为空时生成中断或 µDMA μ s 请求...如果 SSI 已启用并且 TX FIFO 中有有效数据、则通过 SSIFss 主器件信号变为低电平来指示开始发送。 启用主 SSITx 输出焊盘。 在额外的半个 SSIClk 周期之后、主从数据都将启用到各自的发送线路上。 同时、通过下降沿转换启用 SSIClk。 然后、在 SSIClk 信号的上升沿捕捉数据、并在下降沿传播数据。 在单字传输的情况下、在传输所有位之后、SSIFss 线会在最后一个位被捕捉后的一个 SSIClk 周期内返回到其 IDLE 高电平状态。 对于连续的背靠背传输、SSIFss 引脚保持在其低电平有效状态、直到最后一个字的最后一个位被捕捉、然后返回其 IDLE 状态、如前所述。 对于连续的背靠背传输、SSIFss 引脚在连续数据字之间保持低电平、终止与单字传输相同

    我认为、最好让主器件 激活 超过现有 256 的一个或两个字节的时钟、以确保 TX FIFO 已被清除。  

    此致、
    Ryan

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

    您好、Ryan

    感谢您的反馈。

    请您详细说明一下 您的建议吗?
    他们如何要求主器件激活时钟或从器件侧激活两个字节?
    使用此  ui32TransferSize=256→  ui32TransferSize=257 或 258?

    “您可以让主器件  通过时钟线请求额外的字节、并确定是否接收到任何额外的有效数据。“

    “我认为最好让主器件 激活 超过现有 256 个字节的一个或两个字节时钟、以确保 TX FIFO 已被清除。 “

    关于 Q3、在 TRM 上、我们找不到任何解释  TX-FIFO 发送到移位寄存器的触发条件的内容。

    此致、

    Kenley

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

    尊敬的 Kenley:

    是的、它们可以将主服务器的 TransferSize 增加到 257 或 258。  它们可以重复字节 256 、您提醒我、256 个字节来自主器件 (MOSI)、因此我不知道为什么我们讨论从器件 (CC2538) 上的 TX FIFO、而不是 RX FIFO。  根据提供的图表、您是否理解我的困惑?  根据我能说的、CC2538 从器件随时只通过 TX FIFO 发送 8 个字节 (MISO)。  我同意 TRM 关于移位寄存器的操作没有太多要说的内容。

    此致、
    Ryan

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

    您好、Ryan

    很抱歉混淆

    右侧是 MISO 中的 256 个字节。

    此致、

    Kenley

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

    感谢 Kenley 的澄清。  请告诉我他们对我提议的想法的想法。

    此致、
    Ryan

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

    您好、Ryan

    客户正在考虑对保留在 FIFO 或移位寄存器中的数据应用以下对策。 您有任何评论/建议吗?

    1.在设置要使用 DMA 发送的数据之前、检查是否有来自前一帧通信的数据与 SSI_SR:TFE 位进行通信、以查看数据是否为空。

    2.如果该位为空、则在设置传输之前复位 SPI 以清除 FIFO 或移位寄存器。

    3.在提高准备状态以告知主器件允许时钟输出之前、通过观察 SSI_SR:TNF 来检查 TX-FIFO 是否被 DMA 设置的数据阻塞、并等待 TX-FIFO 填满。

    此致、

    Kenley

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

    尊敬的 Kenley:

    请让客户实施这些对策并告诉我结果。  最重要的是在将就绪信号发送到主机之前、确保在 SSI 中充分准备好有效数据。  我假设他们此时无法更改主机侧的固件、这就是为什么所有更改都必须仅在 CC2538 上发生的原因、这是正确的吗?

    此致、
    Ryan