Data ballad
In the first lines of my text I want to say the following: A lot has already been written about this, I will write my own vision. Standard information transfer interfaces are great, but for my needs, they do not provide sufficiently satisfactory (or almost) data transfer. I will make an attempt to make some additions in order to bring it to the state that suits me.
There are 2 or more devices at a sufficiently large (1-100 meters) distance, between which it is necessary to transmit data. Having considered some interfaces (rs232 / 422/485, I2C, Ethernet) I came to the conclusion that they either do not guarantee unambiguous data transfer, I didn’t like a lot of wires either, they don’t give an answer that the information was received. I decided to take the RS485 interface as a basis - from its advantages it can “go far”, 2 wires, you can connect a bunch of devices at the same time, it's simple, (UART) is on almost any controller.
In my case, the classical scheme 1 leading the remaining slaves is suitable for me. The messaging algorithm is as follows: data transfer occurs through exchange cycles, one exchange cycle consists of a message that is transmitted from the master to the slave, in response the master receives a message from the slave, all others are silent. On the same basis, implement the request for receiving data from the slave.
')
One exchange cycle.
To meet my data transfer needs, only two questions are required. Question one: verification of the transmitted byte is based on the RS-485 interface itself, but it does not guarantee a reliably transmitted byte - if a damaged byte is detected in the interface itself, it is thrown out of the received data, but it is still possible to transmit the wrong byte - if it has changed (corrupted ) an even number of bits per byte. those. A check is required for the number of bytes transmitted and the accuracy of the bytes in the transmitted data.
Question two: receiving a response message sent to.
On the first question: the following scheme is proposed: initial byte, quantity byte
transmitted characters in the entire message, something else, checksum byte (BCS), final byte.
Note: read checksum byte by module 2
Based on the proposed scheme, it can be judged that if the answer is not returned, then the slave is not available. In this case, options are possible when a spoiled message reaches the slave and it does not respond to it, or the message reaches it and it sends a response, but the response deteriorates and the master ignores it.
To correct this, it was accepted: if the answer does not come (or comes but unreliable), then repeat (the number of times without insanity) repeat the current exchange cycle. Here the following error may occur. Suppose we send a command to a talking device that we need to add volume to +1 unit. When the message reaches the slave, he executes the command to turn up the volume and sends the answer “ok, I did what you wanted,” it may turn out so that the answer deteriorates and the master does not understand that the command has already been executed, and sends the message again. As a result, after receiving the command on the slave side, the volume will be already increased by +2 units. To avoid such a phenomenon, it is customary to enter an identifier (NA - message number) of the message difference. If the message number is repeated, then this repeated message and the specified command are not necessary, but simply send the previous reply message.
I also enter 2 more parameters here - this is the number (code) of the device to which data is transmitted and the number (subcode) indicating which command to execute (or what data lies within the message).
As a result, I will put everything together and go through the algorithm, using the example of increasing the relay threshold value by temperature by 5 degrees Celsius and taking the current temperature reading from the slave for 1 exchange cycle:
I form the transmitted data from the master:
When receiving a message, the slave looks at 2 bytes, where the number of bytes sent lies, if the number of sent bytes is equal to the number of received ones, then the message has not lost bytes, then we look at the initial byte (character) if it is = '$', as well as the final byte (character) if it = '#', then this message is from the master to the slave.
Immediately consider the possible options for the message from master to slave with errors in the initial and final bytes, as well as a variant with an error count bytes in the message. I will immediately agree from 3 values ​​of parameters I will consider to be correct 2 and 3, i.e. at coincidence of 2 parameters from 3 possible, I consider the message valid.
Next we calculate the checksum of the remaining 3 bytes (bytes 3, 4, 5), if it coincides with the BCS, we continue parsing the data, see if this device has this data and what needs to be done for it, in our case the slave device code 55 and subcode 2 says about the fact that it is necessary to add another 5 degrees to the threshold of the relay and in the response message to send the current data on temperature. I check the NA, if not equal to the previous message number, then I execute the command and add 5 degrees to the current value of the relay threshold. If they are equal (NA), then I do not perform the indicated actions, then proceed to the formation of a response message.
application of the scheme ['$'] [number of sent / received bytes] [...] ['#'] - with high probability guarantees that such a combination will not be able to meet in the transmitted data, and provoke false messages.
I form the transmitted data from the slave based on the received message:
The processing principle is as follows: we look at 2 bytes where the number of bytes sent lies, if the number of sent bytes is equal to the number of bytes received as well as the initial byte = '@' and the final byte = '&' is a message from the slave to the master. If you want to use the mechanism of 2 of 3, the same as described above, only for the response message (for the characters '@' and '&'). When receiving this message, the master analyzes the checksum of 9 (from the 3rd to the 11th) byte, if the checksum matches, the data in the message are considered reliable and further data analysis continues. If the code, subcode and NA of the sent and received message match, we continue the analysis of the response to the message sent by the master. Next comes the analysis of the received data, in my case in the 6th byte the value 1 - indicates that the command to increase 5 degrees to the threshold of the relay is successful, the remaining 5 bytes indicate the current temperature readings of the 7th byte - a flag indicating reliability the transmitted temperature (i.e., considering the option the slave is turned on and responding, and the sensor may not work) and 4 bytes of the type float the temperature value.
The use of 2 check symbols at the beginning and end of a message with a high probability guarantees that the error does not confuse the messages from the slave and the master. Also, random (not random) data in the channel will not spoil the exchange.
It is a little about data transfer to the slave to the slave, and the centralized message to all slaves from the master.
First about the latter - the transfer from the master to the slave is done by assigning the device code 255, telling the slaves that this is a centralized message, then all that remains is to solve the issue of common subcodes, it can also be grouped by device codes ie assign a device code 254 and according to this code 3 or 4 devices will receive the message, the others ignore it, naturally, a part of sending answers from slave devices should not work here - i.e. It is not guaranteed that the slaves unambiguously received these messages!
On the transfer of data to the slave slave, to implement the master method sends a message to the slave (slave1) from which information should be sent to another slave (slave2), the slave1 sends a response to the slave while the slave2 overhears this answer taking data to itself. Again, there is no guarantee about the unambiguous delivery of a message from slave1 to slave2, this must be taken into account!
Interface capabilities: number of theoretically connected devices about 250, commands / data types up to 248 for each device, length of useful information in the message up to 250 bytes.
Let's talk about the underwater stones:
All data transfer is designed to work on time i. certain delays between messages should be observed. I also recommend that you make a fixed delay between the sent message from the master and the slave’s response in order for the slave to generate the data and send it to the channel completely.
The moment of organizing responses from the slave is also important, it may happen that the slave was busy and his channel had data from several messages at once, you should avoid responses to outdated messages (because the master does not wait for them) ignoring them, executing only the latest commands messages and give an answer to it.
Separately, I would like to highlight the issue of synchronization of devices over time - it should be noted that the time synchronization of the slave when receiving a message requires taking into account the time delay for sending data to the channel (at a speed of 9600 a message of 10 bytes will be transmitted about 11 ms) receiving data on the slave side, if there is no interruption, then it is necessary to take into account the time of checking the arrival of data in the device buffer, etc.
It is also worth noting that the repeated sending of the message cycle also adds nuances, I recommend using the sending of a message without repetition for time synchronization, and forming a message with a new NA.
PS I have doubts that I discovered something new here, all this is to some extent used somewhere in different interfaces! With the light hand of the author of this scribbling and the application of this protocol in my workings out, I want to give the name to this data transfer protocol “SRDB2”.
There are 2 or more devices at a sufficiently large (1-100 meters) distance, between which it is necessary to transmit data. Having considered some interfaces (rs232 / 422/485, I2C, Ethernet) I came to the conclusion that they either do not guarantee unambiguous data transfer, I didn’t like a lot of wires either, they don’t give an answer that the information was received. I decided to take the RS485 interface as a basis - from its advantages it can “go far”, 2 wires, you can connect a bunch of devices at the same time, it's simple, (UART) is on almost any controller.
In my case, the classical scheme 1 leading the remaining slaves is suitable for me. The messaging algorithm is as follows: data transfer occurs through exchange cycles, one exchange cycle consists of a message that is transmitted from the master to the slave, in response the master receives a message from the slave, all others are silent. On the same basis, implement the request for receiving data from the slave.
')
One exchange cycle.
To meet my data transfer needs, only two questions are required. Question one: verification of the transmitted byte is based on the RS-485 interface itself, but it does not guarantee a reliably transmitted byte - if a damaged byte is detected in the interface itself, it is thrown out of the received data, but it is still possible to transmit the wrong byte - if it has changed (corrupted ) an even number of bits per byte. those. A check is required for the number of bytes transmitted and the accuracy of the bytes in the transmitted data.
Question two: receiving a response message sent to.
On the first question: the following scheme is proposed: initial byte, quantity byte
transmitted characters in the entire message, something else, checksum byte (BCS), final byte.
Note: read checksum byte by module 2
Based on the proposed scheme, it can be judged that if the answer is not returned, then the slave is not available. In this case, options are possible when a spoiled message reaches the slave and it does not respond to it, or the message reaches it and it sends a response, but the response deteriorates and the master ignores it.
To correct this, it was accepted: if the answer does not come (or comes but unreliable), then repeat (the number of times without insanity) repeat the current exchange cycle. Here the following error may occur. Suppose we send a command to a talking device that we need to add volume to +1 unit. When the message reaches the slave, he executes the command to turn up the volume and sends the answer “ok, I did what you wanted,” it may turn out so that the answer deteriorates and the master does not understand that the command has already been executed, and sends the message again. As a result, after receiving the command on the slave side, the volume will be already increased by +2 units. To avoid such a phenomenon, it is customary to enter an identifier (NA - message number) of the message difference. If the message number is repeated, then this repeated message and the specified command are not necessary, but simply send the previous reply message.
I also enter 2 more parameters here - this is the number (code) of the device to which data is transmitted and the number (subcode) indicating which command to execute (or what data lies within the message).
As a result, I will put everything together and go through the algorithm, using the example of increasing the relay threshold value by temperature by 5 degrees Celsius and taking the current temperature reading from the slave for 1 exchange cycle:
I form the transmitted data from the master:
When receiving a message, the slave looks at 2 bytes, where the number of bytes sent lies, if the number of sent bytes is equal to the number of received ones, then the message has not lost bytes, then we look at the initial byte (character) if it is = '$', as well as the final byte (character) if it = '#', then this message is from the master to the slave.
Immediately consider the possible options for the message from master to slave with errors in the initial and final bytes, as well as a variant with an error count bytes in the message. I will immediately agree from 3 values ​​of parameters I will consider to be correct 2 and 3, i.e. at coincidence of 2 parameters from 3 possible, I consider the message valid.
1. initial byte = '$', number of bytes received = 7 (number of sent bytes = 7), final byte is not equal to '#';
2. the initial byte is not equal to '$', the number of bytes received = 7 (the number of sent bytes = 7), the final byte = '#';
3. starting byte = '$', number of bytes received = 7 (number of sent bytes = 7, number of bytes not equal to 7), final byte = '#'.
Next we calculate the checksum of the remaining 3 bytes (bytes 3, 4, 5), if it coincides with the BCS, we continue parsing the data, see if this device has this data and what needs to be done for it, in our case the slave device code 55 and subcode 2 says about the fact that it is necessary to add another 5 degrees to the threshold of the relay and in the response message to send the current data on temperature. I check the NA, if not equal to the previous message number, then I execute the command and add 5 degrees to the current value of the relay threshold. If they are equal (NA), then I do not perform the indicated actions, then proceed to the formation of a response message.
application of the scheme ['$'] [number of sent / received bytes] [...] ['#'] - with high probability guarantees that such a combination will not be able to meet in the transmitted data, and provoke false messages.
I form the transmitted data from the slave based on the received message:
The processing principle is as follows: we look at 2 bytes where the number of bytes sent lies, if the number of sent bytes is equal to the number of bytes received as well as the initial byte = '@' and the final byte = '&' is a message from the slave to the master. If you want to use the mechanism of 2 of 3, the same as described above, only for the response message (for the characters '@' and '&'). When receiving this message, the master analyzes the checksum of 9 (from the 3rd to the 11th) byte, if the checksum matches, the data in the message are considered reliable and further data analysis continues. If the code, subcode and NA of the sent and received message match, we continue the analysis of the response to the message sent by the master. Next comes the analysis of the received data, in my case in the 6th byte the value 1 - indicates that the command to increase 5 degrees to the threshold of the relay is successful, the remaining 5 bytes indicate the current temperature readings of the 7th byte - a flag indicating reliability the transmitted temperature (i.e., considering the option the slave is turned on and responding, and the sensor may not work) and 4 bytes of the type float the temperature value.
The use of 2 check symbols at the beginning and end of a message with a high probability guarantees that the error does not confuse the messages from the slave and the master. Also, random (not random) data in the channel will not spoil the exchange.
It is a little about data transfer to the slave to the slave, and the centralized message to all slaves from the master.
First about the latter - the transfer from the master to the slave is done by assigning the device code 255, telling the slaves that this is a centralized message, then all that remains is to solve the issue of common subcodes, it can also be grouped by device codes ie assign a device code 254 and according to this code 3 or 4 devices will receive the message, the others ignore it, naturally, a part of sending answers from slave devices should not work here - i.e. It is not guaranteed that the slaves unambiguously received these messages!
On the transfer of data to the slave slave, to implement the master method sends a message to the slave (slave1) from which information should be sent to another slave (slave2), the slave1 sends a response to the slave while the slave2 overhears this answer taking data to itself. Again, there is no guarantee about the unambiguous delivery of a message from slave1 to slave2, this must be taken into account!
Interface capabilities: number of theoretically connected devices about 250, commands / data types up to 248 for each device, length of useful information in the message up to 250 bytes.
Let's talk about the underwater stones:
All data transfer is designed to work on time i. certain delays between messages should be observed. I also recommend that you make a fixed delay between the sent message from the master and the slave’s response in order for the slave to generate the data and send it to the channel completely.
The moment of organizing responses from the slave is also important, it may happen that the slave was busy and his channel had data from several messages at once, you should avoid responses to outdated messages (because the master does not wait for them) ignoring them, executing only the latest commands messages and give an answer to it.
Separately, I would like to highlight the issue of synchronization of devices over time - it should be noted that the time synchronization of the slave when receiving a message requires taking into account the time delay for sending data to the channel (at a speed of 9600 a message of 10 bytes will be transmitted about 11 ms) receiving data on the slave side, if there is no interruption, then it is necessary to take into account the time of checking the arrival of data in the device buffer, etc.
It is also worth noting that the repeated sending of the message cycle also adds nuances, I recommend using the sending of a message without repetition for time synchronization, and forming a message with a new NA.
PS I have doubts that I discovered something new here, all this is to some extent used somewhere in different interfaces! With the light hand of the author of this scribbling and the application of this protocol in my workings out, I want to give the name to this data transfer protocol “SRDB2”.
Source: https://habr.com/ru/post/398791/
All Articles