为什么没有人批准这里的职位？这是我第二次发表这篇文章——第一个似乎已经进入
论坛土地的黑洞。PIC33论坛在哪里？我使用的是DSPIC33 EP512GM710，我正在调用CAN1sEnMeDeAGE（）库程序来发送一个标准的帧（SID＝XXX，EID＝0）。库例程设置TX包的Word2的RB0位（我也在RX侧接收它）。然而，规范表特别声明了ECAN消息缓冲字2，即“用户应用程序必须在每个CAN规范中设置这个位为‘0’。”我注意到，Microchip自己的源代码（在CAN1sEndiaMicro.C中）明确地设置了位。那给了什么？它应该是什么，或者重要吗？我使用回环模式，它发送/接收罚款不管RB0位被设置或清除（我实现sEndoMeXAGE（）手动，所以我可以迫使位明确）。在RX端，比特被接收到与它发送的（0或1）相同，但我不相信回送模式来表示真正的CAN总线上的正确活动。没有与此相关的勘误表。有人能解释一下吗？感谢琼斯
以上来自于百度翻译
以下为原文
How come no one approves posts here? This is the second
time I've posted this - the first appears to have gone into the black hole of Forum-Land. And where's the PIC33E Forum?
I'm using dsPIC33EP512GM710 and I'm calling the CAN1SendMessage() library routine to send a Standard frame (SID=xxx, EID=0). The library routine sets the RB0 bit of Word2 of the Tx-packet (I also receive it on the Rx-side). However, the spec-sheet specifically states for ECAN Message Buffer Word 2 that the "User application must set this bit to ‘0’ per CAN Specification."
I note that Microchip's own source code (in CAN1SendMessage.c) explicitly sets the bit. So what gives? Which is it supposed to be, or does it matter?
I'm using Loopback Mode and it sends/receives fine regardless of the RB0 bit being set or clear (I implemented SendMessage() manually so I could force the bit clear). On the Rx-side, the bit is received the same as it was sent (0 or 1) but I don't trust Loopback Mode to represent proper activity on a real CAN-bus.
There are no errata relating to this.
Can anyone shed any light on this?
Thanks
jjones
举报
