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.
您好!
我正在使用我们在两个 RM48之间实现的通信总线。
Micro X 是主器件、并将数据发送到微型 Y、后者是从器件、使用 MibSPI、其布局与应用手册 SPNA231 (在 Hercules 上使用 MibSPIP 模块的高速串行总线)中所示的布局非常相似:
它运行良好、但我需要使它在同步方面更可靠:我担心 X 不知道从器件是否处理了接收到的数据。 由于 DMA 的原因、数据在 SRAM 中、但如果从器件不移动 DMA 目标指针或移动数据、主器件可以开始另一个覆盖数据的传输。
我想我可以使用 ENA 来同步偶数帧传输。 如果在传输后从器件禁用其 MibSPI 传输组、它将起作用。 我尝试通过手动禁用组来执行此操作、它起作用、从器件不移动 ENA、主器件进入 ENA 超时、不会发生数据覆盖。
下面是我的问题、
谢谢!!!
PS:要找到一个有效的解决方案,我需要在这个论坛上了解从 MibSPI 的未记录行为(CS 编码、CSHOLD ...)。 我希望更新正式的 TRM 以包括一个针对从器件 MibSPI 的部分、这些勘误表和缺失 已有多年的历史了、RM48的 TRM 已有4年历史了。 如果我的认证机构知道我的安全关键型应用是利用未记录的功能开发的....
PPS:我真的要感谢您 在这个论坛上提供宝贵和耐心的帮助
1.“如果您使用类似的方法”
是的、双 DMA 传输的方法类似、但我有一个由128个缓冲区组成的传输组、我通过两个 DMA 传输将数据传输到 SRAM、每个传输应用于64个缓冲区。
2.“由于 TG 永远不会被填满,单次击球可能不会按预期表现”
这似乎不是真的。 我尝试完全禁用 DMA 传输、但 TG 无论如何也不会被禁用。 我看到128个 MibSPI 缓冲器中填充了主器件的新数据(覆盖旧数据)、但 TG 仍处于活动状态。 实际上、如果我再次从主器件发送数据、我会在从器件缓冲区中再次找到新数据。 我无法以任何方式自动禁用从器件侧的 TG。 我缺少什么?
3、您的想法1 (避免使用 DMA 并使用 CPU 从 MibSPI 缓冲器传输数据、在数据处理后重新启用 TG)
同时放弃 DMA (这是我想避免的事情),因为第2点的问题,它目前对我不起作用
4.您的想法2 (Nena 引脚设置为 GIO)
如果我理解得好,这似乎不符合我的需要。 如果我手动使能传输、我无法保证从器件的速度足够快、可以手动禁用 ENA 并避免第二次传输。
无论如何、这会打开另一个奇怪的现象:如果在从器件侧 ENA 被设定为 GIO 并且 DMA 传输被启用、一个或两个数据字将丢失。 从机接收到的是前64个缓冲区、这些缓冲区触发了第一个 DMA 块传输、之后第二个或第三个数据从未接收到、这样、64个缓冲区中的第二个块永远不会被填满、结果是从机被去同步。 如果 MibSPI 在 DMA 传输下、似乎在某种程度上忙线并丢失传入的数据。 如果我将 ENA 设置为功能或禁用 DMA 传输、则不会发生这种情况。 您能找到原因吗?
5.您的想法3 (放弃使用 TG,将其设置为标准 SPI)
这似乎是一个选项、但我想利用 MibSPI 缓冲器提供的大量放松时间要求。
6.您的最终选择(创建另一个缓冲区)
如果我理解正确的话,这就是我目前所做的事情。 我有64个缓冲区可触发 DMA 传输、另有64个缓冲区可触发另一个 DMA 传输。 但这也不能保证与主器件同步。
因此、如果您对第2点有任何建议、我想再试一次、否则、我将选择另一种遵循您的想法的方法、很遗憾、我放弃了一些 MibSPI 功能。
感谢您的关注、
Valerio
你好、Chuck、
不幸的是,这不是我想要的方式。 由于没有来自 TI 的答案、并且缺少有关 MibSPI 主题的 TRM 文档、因此我将尝试另一种方法。
我的解决方案与 https://e2e.ti.com/support/microcontrollers/hercules/f/312/p/158061/1978463中描述的解决方案类似。
我使用 DMA 链获取循环缓冲器:一个 DMA 通道传输数据、另一个(链中)将计数器传输到变量中。 读取该变量、我知道 DMA 已传输的帧数。
这是可行的、但我不喜欢:
因此、目前我想我将采用这种方法来管理所有数据流上的缓冲区溢出。 这由 MibSPI 缓冲器和 DMA 循环缓冲器延迟、但仍然可以。
Valerio