Design of communication protocol in embedded system

Source: Design of communication protocol in embedded system

That's wonderful!

Companies do projects, embedded systems are large and small, everywhere. Because all are in a system, so all need communication, since the communication is related to the protocol problem.

Talking about the agreement, many engineers feel that the design of the protocol is relatively simple, mainly the design of the message. Most of the time, the protocol scenario is simple and has no complex interaction. There is no big problem with that. However, it is such a simple scenario that there are still some protocols that can actually cause unexpected problems. In the final, there is no grasp of the law of the Agreement. Let's briefly talk about the rules of protocol design.

Issues facing the design of the Protocol:

1. Most of the designers, from the application, only considered the basic needs of the satisfaction, did not consider the expansion of the needs of the satisfaction;

2. From the OSI seven layer theory, we often design the agreement when standing in the higher level of the design, often ignoring the rs485/rs232, i²c, CAN, Ethernet and other physical layer bearing characteristics, design lack of specific application of pertinence, leading to the emergence of potential problems;

3. Lack of tolerance and efficiency considerations.

The basic requirement is definitely the basic function of completing the system. However, because the definition of requirements is incomplete, the system Designer is not forward-looking; there is no version number defined in the agreement, there is no test for protocol compatibility, and the old product and the new product agreement are incompatible, but cannot be solved by simple software method. This is a common problem, the simplest way is to increase the protocol version number in the handshake protocol, to determine whether to support the Protocol and to prepare for the subsequent software compatibility. The agreement seems to be only the message design, like a person, he in the eyes of parents is always a child, in front of their children are parents, friends in front of friends. I believe that all these sides together is a complete person. UML from different angles to observe the system will get different graphs. The same is true of the Protocol, which is only one aspect of the static nature of the Protocol, and the Protocol has more important dynamic characteristics. What should I do after an error, re-send? How many times is it repeated? How is node corruption removed from the network? What is a complete communication process? How long is it going to last? What is the worst case scenario? What's the best case scenario? Who initiated the newsletter? Important agreements can be guaranteed to be very reliable, how to determine that the recipient is receiving exactly the right and reliable execution? Often these problems are beyond the consideration of the message itself, but rather a design of the system solution. Here is a small example, a RS485 semi-work communication, the host to the slave to send data, want to reliably save the data from the machine, the slave received the data after verification, write to its own storage device, and then respond to the host, write success or failure. But here's the problem, RS485 is a master/slave structure, unable to send data at the same time, only the host name from the machine to respond. If the write time is too long, the slave will be too long to respond to the message, and if the slave is a lot, the time will not be wasted. May be modified to receive the host's information immediately after receiving it from the machine. The host then distributes the data from other slave computers, and after distribution, the host uses the query protocol to query the success of the slave writing. Of course, you can also adopt some system-level approach, as long as the slave receives the data, the slave must ensure that the data is written successfully, then the problem becomes simple. The host also does not have to query whether the write succeeded. The design of the software is relatively simple and much simpler.

RS485/RS232 also has duplex communication, but it is used less in practice. Here in addition to the province wire, I am afraid that the most important thing is because the rs485/rs232 without conflict detection, or the use of the wheel pile as a host, or a host, named to let everyone speak the way. Therefore, the communication using a question and answer method is more, this is more in line with the work of the semi-working state. Of course, some duplex application scenarios are not ruled out. In practical applications, the majority of the use of semi-industrial methods. The design of the protocol here mainly consider a large number of single points, multicast and unicast, because it is not possible to determine whether the slave receives success, so important protocol after multicast and broadcast to query, this is a very troublesome thing. The software process is therefore much more complex. RS485/RS232 communication has its own method of detecting errors, such as parity check, parity is a simple error check, and can not block error 100%, for the reliable Protocol, it is possible to design their own CRC or calibration and other methods. But although CRC check can be used to look up the table, but the calculation time than parity and checksum and other methods of calculation is too large. In some real-time and low-end applications, it may be time-expensive. Therefore, if the message is not too large, or can consider parity and checksum, if too large, first consider Crc8, and then consider CRC16 and CRC32, do not cut a pole.

I²c communication is generally used only on board level, but now there is a trend for fieldbus. At the beginning of the design is to support multi-master multi-Slave, two hosts can send information at the same time, the host wins the quorum to get the bus, continue to send. There is arbitration does not mean that the two-way message can be sent at the same time, that is, the host and slave status or different, host name from the machine response information; Although now the CPU with the I²C hardware support both main mode and slave mode, but at the same time, the two modes are incompatible. For a node either the master or the slave, and each communication is initiated by the master, from passive reception, which leads to no essential difference from RS232. And, the physical layer of the Protocol also decided, its communication mode is not RS232 flexible, can only work in the semi-working state. Two CPUs pass some simple information, which is very useful if the CPU has no extra rs232. Because it is board-level communication, the integrity of the signal is guaranteed, there is basically no error, and no additional calibration methods are required.

Ethernet and can bus are similar, all nodes are equivalent, no master and Slave said, who can initiate information. Because of the conflict detection, the failure of the quorum node to retry later, the physical layer completed, no need for software participation, thus to the protocol design has brought great convenience. For example, the previous problem, a broadcast protocol out, no longer like rs232/rs485, and then to one by one query confirmation. It's good to report problems directly to the device. Greatly simplifies the handling of the problem. rs232/rs485 node If there is a problem, you need to report, you can only wait until the host name to be reported. Ethernet/can will not have to, after the problem, directly upload. To ensure timely handling of problems and emergencies. If the Ethernet is TCP-based protocol, the efficiency is low, but it guarantees a lot of features, the order of data arrives, the reliability and so on. Under the IP layer of the Protocol has a big problem is not to guarantee the order of data arrival, the length of multiple paths will affect the order of arrival of the protocol, some systems in the design for efficiency, using UDP or Mac layer of direct communication. Then it is better to adopt a more conservative strategy to prevent the protocol message from arriving to produce unnecessary errors. Ethernet physical layer with CRC32 verification, it is not necessary to do their own verification.

The efficiency of the

Protocol is a more complex topic, taking RS232 as an example, RS232 if 1 start position, 1 stop position, no parity. Then sending a byte requires 10Bit, for a 9600bps baud rate, 1 seconds to transmit up to 960 bytes. is about 1ms a byte. If the stop bit is longer, the number of useful bytes that the protocol transports at one time is even lower. Removing the necessary frame head, frame end, address, checksum information, the truly useful information divided by the total number of bytes shipped on the bus, is the protocol carrying capacity. Obviously, if I use multicasting and broadcasting, it obviously improves efficiency. For RS232, broadcasting may not be a good choice, especially if you look back and confirm it again. Maybe it's a good idea to raise the baud rate. The problem with this is that 1Mbps communication system, 1start,1stop, non-parity, 1 bytes only need 10us, so fast interrupt is not normal CPU can withstand. Therefore, DMA may be required to receive. If DMA is received, it involves a variable-length protocol and a fixed-length protocol. The variable-length protocol is to dynamically determine whether a complete package is received, while the fixed-length protocol has unparalleled advantages for high-speed RS232. Greatly reduce the complexity of the calculation. A fixed-length protocol involves the length of the protocol. We generally use the length of the most frequently occurring protocol as the length of all protocol messages. For ultra-long protocol, due to the use of a few times, split into a number of fixed-length protocol bar message is complete. For example, our system control command length is the length of all protocols, since 80% of protocol messages are system control commands. and 20% of the message is other low-frequency messages, such as the system firmware upgrade message, the size of its own firmware is very large, even if the ultra-long message can not be accommodated. Cut into the same length as the control command message. Seemingly more fragmented, each package has its own independence. Can do a separate message transmission, the coupling to a minimum before and after, that is, although the large protocol is split into small equal-length protocol messages, each of the long message in the sending process error, can be sent separately, the entire communication sequence without resetting. Through reasonable design, the efficiency of the agreement is naturally promoted.

Ethernet's design is relatively loose, its bottom is too strong. A lot of work has been done, so the unequal length of the Ethernet system does not matter. The key is to solve the Ethernet communication model problem. In the case of an embedded server, TCP maintains a half-open link that is not too resource-intensive. In the case of UDP or MAC layer protocols, it is necessary to decouple the sequence of protocol sequences to prevent unnecessary problems. If a large protocol package, need to be split into three packets sent, three packet order without any impact, any packet error, only need to resend the error packet successfully. Ethernet due to the high speed, the protocol carrying capacity can be well supplemented. In addition, because Ethernet is a perfect support multicast and broadcast network, the actual use of broadcast too much caused the broadcast storm, resulting in a sharp decline in network performance, so now divided the virtual LAN, is to suppress the broadcast storm, improve efficiency. In practice, we should design the system as reasonably as possible, avoid excessive use of broadcast protocols, so as not to slow down the whole network system.

Design of communication protocol in embedded system (turn)