某些节点不响应的CAN总线

我正在开发一个CANopen主机，它将管理一批CANopen奴隶（一个或多个）。不管协议的其他细节，它使用一个主/多从拓扑，其中主机可以根据SIP中的地址发送命令，例如重置或启动奴隶。据我所知，在一个节点中，一个节点发送的消息必须被至少另一个节点所确认，在某些情况下，我看到了主机的TX-FIFO，它的消息充满了待发送，显然是因为没有接收到ACK，或者看起来是什么样子。如果我在AutoBoopRead模式下配置一个奴隶，因为它通常需要分析几个数据包来检测波特率，如果总线中只有一个在TX FIFO被阻塞时，就不可能执行检测。因此，为了防止主从当奴隶DOE被阻塞。SN不响应，我的想法是使用1消息TX FIFO，并中止当前转移，如果我检测到超时。当这种情况发生时，我认为我应该遵循的步骤是：（PIC32 MX）：1。设置CXCON.ABAT2。等待，直到CXCON.ABAT为0（传输已被中止）3。设置CXFIFON。等到CXFIFOCON.FREET是0（FIFO已经被复位）使用1消息FIFO将很容易处理所有指针的东西，并允许我重置FIFO，而不必注意哪个从节点是不正确工作的，或者有ALL的节点发生了什么。阿迪排队等候留言。我知道，这需要一些额外的高层控制，但这不是问题。问题是：当我说FIFO不会因为没有接收ACK而消耗数据包时，我是对的吗？这是中止转帐的正确方法吗？-发送消息时会发生什么？它会永远在公共汽车上吗？当做
                    
                    
               
                                                                                      以下为原文

                                                                            Hi


I'm developing a CANopen master, which is going to manage a number of CANopen slaves (one or more).


Regardless of other details of the protocol, it uses a master / multislave topology, where the master can send commands such us RESET or START to slaves based on their addresses, encoded in the SID.

As far as I know, in CAN bus a message sent by a node must be acknowledged by at least another node, and I've seen in some cases the TX FIFO of the master full of messages pending to be sent, apparently because no ACK has been received, or that's what it looks like.

Another scenario similar to this happens if I configure a slave in autobaudrate mode, because it usually needs to analyse several packets so as to detect the baudrate, and if there's just one in the bus while the TX FIFO blocked, no detection can be performed.

So, in order to prevent the master from getting blocked when a slave doesn't respond, my idea is to use a 1-message TX FIFO and abort the current transfer if I detect a timeout. When this happens, the steps I think I should follow are (PIC32MX):
1. Set CxCON.ABAT
2. Wait until CxCON.ABAT is 0 (the transfer has been aborted)
3. Set CxFIFOCONy.FRESET
4. Wait until CxFIFOCONy.FRESET is 0 (the FIFO has been resetted)

Using a 1-message FIFO would make easy to handle all the pointer stuff and would allow me to reset the FIFO without having to pay attention to which slave node is the one not working properly or what happens with the nodes that have already enqueued messages. This would need some extra control from upper layers, I know, but that's not a problem.

And the questions:
- Am I right when I say the FIFO is not consuming packets as a consequence of not receiving an ACK?
- Is this the right way to abort a transfer?
- What is expected to happen with the message being sent? is it going to be there in the bus "forever"?

Regards