[参考译文] TMS320F28377D：无法使用示例代码实现 CAN 外部环回模式运行

Yi、

           仅更改 GPIO 分配不应影响示例的工作方式。 问题：

 

1. 在运行示例"按原样"时、您是否能够查看数组中的数据？ (即、具有原始 GPIO 分配)
2. 您是在自检(环回)模式下运行此代码还是正在尝试与另一个节点通信？
3. 您使用的是什么硬件平台？
   

您好、Haresh、

感谢您的及时答复。
1。
我返回到原始示例代码并进行简单更改
*(unsigned long *) ucRXMsgData = 0；
更改为
*(unsigned long *) ucRXMsgData = 48；
现在、我可以观察到值为"0"。 我认为是因为与 ASCII 代码对应的字符、我以前看不到任何有意义的内容。 尽管引脚分配是"错误的"、但它似乎已经在运行自检。 这是否意味着我无需将 CAN 引脚连接到收发器进行自检、并且可以分配任何 GPIO (CAN)引脚以在自检模式下运行？
2.
我首先尝试在回送模式下运行此代码以演示其功能并加深我的理解。 然后、我需要与另一个节点通信
3.
我使用 SN65HVD235作为收发器、并尝试最后与 imx6进行通信。

它看起来是示例代码、我可以继续对其进行修改。 另一个问题：我想在 CPU2上运行 CAN 通信、在这种情况下、我需要将 GPIO 引脚分配给 CPU2、并按如下方式选择 CAN 对 CPU2。 是否有其他可配置在 CPU2中运行的内容？
GPIO_SetupPinMux (4、GPIO_MUX_CPU2、6)；
EALLOW；
DevCfgRegs.CPUSEL8.bit.CAN_A = 1；
DevCfgRegs.CPUSEL8.bit.CAN_B = 1；
EDIS；

最棒的
Yi

您好、Haresh、

我运行了几次示例代码、发现了另一个问题。 虽然它可以在前几百个循环中成功运行、但它将在大约"\377"处停止。 如所示

*(unsigned long *) ucRXMsgData = 48；

显示、它现在是"long"类型、应该大于该类型。 和一样

无符号字符 ucTXMsgData[4]

显示、如果该值增加到255、则应自动从 ucTXMsgData[0]加载到 ucTXMsgData[1]、对吧？ 在本例中、我可以像 ucTXMsgData[0]中那样观察数字或符号(对应于 ASCII)、但不会发生任何情况。 我想知道限制应该是多少。 我很困惑、因为有很多强制类型转换、您能给出一些提示吗？

第一张图片是正常的功能、第二张图片是在错误发生前第二次发生的情况。 (G_ulMsgCount = 1表示错误)

[引用用户="Yi Zhang ]Hi Haresesh、

感谢您的及时答复。
1。
我返回到原始示例代码并进行简单更改
*(unsigned long *) ucRXMsgData = 0；
更改为
*(unsigned long *) ucRXMsgData = 48；
现在、我可以观察到值为"0"。 我认为是因为与 ASCII 代码对应的字符、我以前看不到任何有意义的内容。 尽管引脚分配是"错误的"、但它似乎已经在运行自检。 这是否意味着我无需将 CAN 引脚连接到收发器进行自检、并且可以分配任何 GPIO (CAN)引脚以在自检模式下运行？

回答：正确。

2.
我首先尝试在回送模式下运行此代码以演示其功能并加深我的理解。 然后、我需要与另一个节点通信
3.
我使用 SN65HVD235 作为收发器、并尝试最后与 imx6进行通信。

它看起来是示例代码、我可以继续对其进行修改。 另一个问题：我想在 CPU2上运行 CAN 通信、在这种情况下、我需要将 GPIO 引脚分配给 CPU2、并按如下方式选择 CAN 对 CPU2。 是否有其他可配置在 CPU2中运行的内容？
GPIO_SetupPinMux (4、GPIO_MUX_CPU2、6)；
EALLOW；
DevCfgRegs.CPUSEL8.bit.CAN_A = 1；
DevCfgRegs.CPUSEL8.bit.CAN_B = 1；
EDIS；
回答： 您需要对所有相关的 GPIO 引脚执行此操作。

最棒的
Yi

[/报价]

[引用用户="Yi Zhang "]

您好、Haresh、

我运行了几次示例代码、发现了另一个问题。 虽然它可以在前几百个循环中成功运行、但它将在大约"\377"处停止。 如所示

*(unsigned long *) ucRXMsgData = 48；

显示、它现在是"long"类型、应该大于该类型。 和一样

无符号字符 ucTXMsgData[4]

显示、如果该值增加到255、则应自动从 ucTXMsgData[0]加载到 ucTXMsgData[1]、对吧？ 在本例中、我可以像 ucTXMsgData[0]中那样观察数字或符号(对应于 ASCII)、但不会发生任何情况。 我想知道限制应该是多少。 我很困惑、因为有很多强制类型转换、您能给出一些提示吗？

第一张图片是正常的功能、第二张图片是在错误发生前第二次发生的情况。 (G_ulMsgCount = 1表示错误)

[/报价]

您好！

在寄存器视图中、您可以右键单击 TX 和 RX 数据数组、并将显示格式更改为十六进制以更好地查看数组的内容。

错误(TX 和 RX 数据不匹配的哪个错误)总是在同一个点发生？

此致

Chris

尊敬的 Chris：

我认为"\377"对应十进制的"255"、即使我给单个数组成员而不是整个数组取值、错误仍然会发生。 "\377"错误似乎总是在数组的最高成员处发生。

因为当我进行这样的编程时：

txMsgData[0]= 0x12；
txMsgData[1]= 0x12；
txMsgData[2]= 0x12；
txMsgData[3]= 0xEE；
txMsgData[4]= 0xE0；

然后在每个 for 循环期间将每个成员增加1。 只有当 txMsgData[4]增加到"\377"时、才会发生错误。

但是、如果我按如下方式进行编程：

txMsgData[0]= 0x12；
txMsgData[1]= 0x12；
txMsgData[2]= 0x12；
txMsgData[3]= 0xE0；

只有 当 txMsgData[3]增加到"\377"时、才会发生错误。

我很困惑这是如何仅发生在最高字节的。 在我使用"if"来标识"\377"点并将其清除为零之后、没有错误。

您能就此提供任何提示吗？ 由于它们是以单独的字节写入的、因此即使一个字节超过其限制、也不应存在冲突。

谢谢、

Yi

Yi、

我进行了一些测试、但我没有看到数据匹配错误。 我确实认为需要修复此示例、以单独递增每个数组索引的数据。 此外、我将提交一个错误、添加一个已检查的错误、以便每当任何索引超过0xFF 时、它们都将重置为零。 当数据递增到超过0xFF 时、它会回滚到0x100、然后发送零(驱动程序 API 只接受较低的字节)。

此致
Chris

尊敬的 Chris：

感谢您回来。 我对代码进行了类似的修改、结果没有问题、至少现在没有错误。 但是、正如我在上一个帖子中提到的、即使其他索引在前面增加到0xFF、也没有错误、它们将返回0、然后重新开始。 但是、最高索引的情况有所不同、它在增加到0xFF 时显示错误。 这是我现在仍然感到困惑和好奇的地方。 如果现在没有快速的答案，我完全可以理解。 无论如何、非常感谢。

Yi