The realization of 6 kinds of serial port protocols

》》Serial port protocol development
	The following parsing paradigms are stored in the shape of the data queue, and according to the difference in the running speed of the device, a packet queue needs to be added to store the parsed packets.

1. Paradigm 1 "fixed length" without verification
		
		0x6B----------20 bytes-------0xB6
		In the above data, there is a frame header 0x6B, a frame end 0xB6, and 20 intermediate data.
		Every time the data needs to find the frame header 0x6B, it starts to store. After reading 22 bytes, the storage ends, and it is judged whether the last byte is 0xB6.
		
		If there is an error in this paradigm, the entire packet will become an error packet, which is more dangerous.

1. Paradigm 2 "fixed length" has verification
		
		0x6B----------20 bytes-------check-0xB6
		In the above data, there is a frame header 0x6B, a frame tail 0xB6, 20 intermediate data, and a check code in front of the frame tail.
		Every time the data needs to find the frame header 0x6B, it starts to store, after reading 23 bytes, the storage ends, and it is judged whether the last byte is 0xB6.
		And judge the check code.
		
		This paradigm solves the bit error problem that occurs above.

1. Paradigm 3 "unfixed length" without verification
		
		0x6B----------N bytes---------0xB6
		In the above data, there is a frame header 0x6B, a frame tail 0xB6, N pieces of intermediate data, and a check code in front of the frame tail.
		Every time the data needs to find the frame header 0x6B, it starts to store, and after reading 0xB6, the storage ends, and it is judged whether the last byte is 0xB6.
		
		
		This paradigm will have the problem of wrong unpacking. For example, if 0xB6 data appears in the data, the packet will be lost.
		There will still be errors.

1. Paradigm 4 "Unfixed Length" has verification
		
		0x6B----------N bytes-------check-0xB6
		In the above data, there is a frame header 0x6B, a frame tail 0xB6, N pieces of intermediate data, and a check code in front of the frame tail.
		Every time the data needs to find the frame header 0x6B, it starts to store, and after reading 0xB6, the storage ends, and it is judged whether the last byte is 0xB6.
		And judge the check code.
		
		This paradigm solves the bit error problem that occurs above.
		This paradigm will have the problem of wrong unpacking. For example, if 0xB6 data appears in the data, the packet will be lost.

1. Paradigm 5 "Unfixed Length" has checksum, adding escape characters
		
		0x6B----------N bytes-------check-0xB6

		If there is 0xB6 data in the data, then the packet is terminated early, which is not the data we want.
		Escape characters need to be added here

		0xB6   ->		0xBf,0x01
		0xBf   ->		0xBf,0x02

		In the above data, there is a frame header 0x6B, a frame tail 0xB6, N pieces of intermediate data, and a check code in front of the frame tail.
		Every time the data needs to find the frame header 0x6B, it starts to store, and after reading 0xB6, the storage ends, and it is judged whether the last byte is 0xB6.
		And judge the check code.
		Need to parse specific escape characters
		
		This paradigm solves the bit error problem that occurs above.
		This paradigm does not suffer from incorrect unpacking.

1. Paradigm 6 "unfixed length" has verification
		
		0x6B-0xB6-N data length---------N bytes---------check

		There is a frame header 0x6B, 0xB6, data length, N intermediate data, and check code in the above data.
		Each time the data needs to find the frame header 0x6B before it starts to store, after reading the data length, read the corresponding length, and then read a check code.

		You can determine the verification code.
		
		This paradigm solves the bit error problem that occurs above.
		This paradigm does not suffer from incorrect unpacking.


2018-2-13:

The above are all single frame headers. In order to ensure safety, it is best to use double frame headers, three frame headers, and four frame headers. It depends on the actual situation.




Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=325585900&siteId=291194637