About bus conflicts (Part 1)

RCSN

About bus conflicts (Part 1) [Copy link]

 

This is also a series of posts, about the topic that I always want to know: about the bus. I always want to know how to learn CAN, but I want to write two posts . If the author uses inappropriate words in the post, I hope you can communicate and correct them. In this post, I will use half-duplex bus as the theme of the bus, one RS485 bus and one CAN bus. Because of half-duplex, in most cases, we need to consider a problem: in the case of multiple slaves, how to avoid "simultaneous" sending to the host, how to send in order without causing bus chaos, this is a problem that needs to be considered when there is only one bus. Especially when you need to broadcast to read a certain information from the slave, if you don't have an anti-collision mechanism, the messages sent on the bus will probably be a bunch of garbled codes. This post mainly describes the RS485 bus, and the MCU uses STM32. The RS485 bus does not have a hardware bus arbitration priority like CAN. To be precise, all nodes can be either the master or the slave. How to prevent the bus from causing conflicts? For RS485, the host also has a solution, which is to use each node with a node address (dip switch, information hard-coded binding, etc. are all possible), and use software delays to detect whether the bus is idle + DMA sends to quickly seize the bus to prevent conflicts. The following host only explains its principle process. The code screenshot process may not be very clear, but I will try my best to make the idea clear. This content is originally created by RCSN, a netizen of the EEWORLD forum. If you need to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source

RCSN

Here, the author still uses a broadcast to read the software version number, and each node slave returns the version number as an example to explain. The RS485 bus needs a conversion chip to communicate with the microcontroller, and must convert TTL, that is, the corresponding serial port. Common chips include Maxim's MAX485, etc. There will be a transmit and receive enable pin. The two enable pins should not be enabled at the same time. Once powered on, the default is to enable reception. When there is data to be sent, the transmission is enabled again. After the transmission is completed, the reception is enabled again. In this way, polling is performed for communication. In the end, it is still a serial port problem, but compared with the serial port, it is more important to note that the transmission and reception cannot be simultaneous. In bus communication, the author is accustomed to using FIFO queues to send and receive data for asynchronous processing, that is, no matter whether there is data received or to be sent, all are put into the FIFO queue. Of course, if you use RTOS, you can also use message queues to send and receive data. So we need to do an initialization step: initialization of some related variables, initialization of FIFO queues, initialization of related IO, initialization of related interrupts. Then in terms of interrupts, we enabled three interrupts, one for the receive completion interrupt, the idle interrupt, and the DMA send completion interrupt (the HAL library used by the OP, the DMA send completion of the HAL library will enable the serial port send completion interrupt). So in the global interrupt we need to judge these three interrupt events and do some corresponding event logic processing.

RCSN

The analysis of the receiving part will not be explained, because the things involved seem to deviate from the topic. So what we need to consider is how to avoid conflicts between our own nodes and other nodes when sending. We don't need an idea yet, that is, to judge whether the receiving end level on the bus is pulled down as whether the hardware bus is idle. The previous idle interrupt only plays the role of not sending and receiving data on the node for the first time. To really be able to send in an orderly manner, the host still uses different nodes with different delays to block to judge whether the receiving end level is pulled down as the sending priority. The lower the address of the node, the easier it is to seize the bus and send first. Then on the sending interface, we need to judge whether the DMA sending completion flag is established on the DMA sending. If not, an error is returned and the sending continues after one polling. Here we store the data to be sent in a buffer and wait until the bus is seized before sending, so here we need to change the sending status variable. Then poll and detect the status of this variable in the task.

RCSN

Then we can create a thread or task, once every 2ms, to detect whether the anti-collision flag is valid, and then determine whether it is idle to decide whether to send.

lcofjp

Thanks for sharing! Like it!

迈尔风随

This mechanism will only work well if all nodes in the entire network comply with it, otherwise conflicts will still occur.

RCSN

lcofjp posted on 2018-11-24 11:11 Thank you for sharing! Like it!

Thank you for the support of the captain: kiss:

eric_wang

Thanks for sharing your experience

RCSN

Mayer Fengsui published on 2018-11-24 11:35 This mechanism will only work well if all nodes in the entire network comply with it, otherwise conflicts will still occur

All nodes comply with it, that is, they share a set of such mechanisms. However, this mechanism cannot guarantee 100% non-conflict. In my actual project, 96 nodes can achieve a 95% non-conflict probability

ljj3166

, what a rip-off

elvike

ljj3166 posted on 2018-11-24 22:20, it’s really bad

, it’s really bad

elvike

, good abuse