Design of serial port receiving data scheme

This article is an experience note , Record the strategy of serial port receiving data analysis encountered in the work .

        This paper takes serial port as an example , But it can also be extended to other places where two devices communicate , As long as it involves data transmission and transfer , There will be communication , As long as the processing speed of communication devices is different, there will be a cache , Only cache , It will involve the organization form of data , The first in, first out mode corresponds to most communication situations in the real world , Queues become the best choice for caching . The size of the queue is processor dependent , Also related to application . A reasonable choice should be made when every packet of data comes , There is enough space to receive , And the program can process the cached data and generate enough space before the next packet of data comes .

The serial port receiving data should be interrupt mode in essence , But the data processing is different .

The first pattern ： Interrupt handling , Interrupt processing means that the parsing processing function is executed in the interrupt callback function , Suitable for small data volume .

Second mode ： Query processing , There is no delay in the program , Just check whether there is data coming in , Operate when there is data , This situation is suitable for receiving instructions .

The first pattern ： timer mode , In this mode, the period of sending data by the sender is known , And determine the length of each frame of data , In this way, a timer with equal time is used in the program to receive and process the corresponding information each time .

In analytic functions , According to the data reception, there are several situations ;1, The data is not ;2, There is data, but only a little , Not enough for a frame ;3, Exactly the length of one frame ;4, Longer than one frame , Insufficient 2 frame ;5, Too much data exceeds the cache area .

In the above case , Do nothing without data , Just wait for the data ; Too much data out of the cache , This situation should be considered and avoided when designing and testing , Whether it's an extended cache , Or optimize function processing time , Or reduce the frequency of the sender . In the actual process of program operation, most of them belong to 2-3-4 The situation of ,4 After a frame is processed , It becomes 2 The situation of , So the main thing is to deal with 2-3 This situation , What to do when the data is available but it is less than one frame ？

My answer is to continue to wait , But not a blocked wait , In that case , The initiative of the receiver depends entirely on the sender . In the analysis of each frame of data , There are usually some features to extract , Like frame header , Frame tail , length , Verification and special characters defined by both parties . Communication protocol is the data format that we all abide by , Parsing is based on the protocol . How to wait ? Take the following characters as an example ：

$CSDN,6,abcdef,07\r\n

In the data shown above , The frame header is $CSDN, The data is separated by commas , The first 2 Segment data indicates length , The first 3 Segment represents data , The first 4 Segment XOR checksum ,\r\n Indicates the end of the data .

When the program first looks at the received data , Probably only received $ A byte , This may be the beginning of valid data or a garbled code , Let's start with a valid character , Record in a Array （ This array represents the valid data we are going to parse ） in , The next test found that C, At this time, we continue to add this character as valid data to the array , Check in turn until you encounter a carriage return line feed , At this time, it is considered that a complete frame has been received , Then carry out inspection and other treatment ; If an error is sent in the data, such as $CSE, That is, when the fourth bit transmission error does not satisfy the header , Or if the verification fails, we think the data is abnormal , Empty array , Continue to receive and find the frame header . What if we record the current status of the received data ？ Now that the status has been mentioned , Then you can naturally think that this is a state machine , There is no data --- There's data -- Complete data --- Processed --- There is no constant jump between data . So this can be achieved .

Let's add a little more difficulty , If there are various data formats , Different lengths , How to deal with different frame headers and frames ？ Is the method mentioned above still applicable ？

Let's start with my understanding , The above method can still be used , To make some changes and expansion . Consider all data formats , And match various possible frame headers to the received data , As long as the header and footer of the data frame match , It is considered as a complete frame of data , Checksum parsing is then performed .

When there are many data formats , There are two situations , One is interactive , One is pure receiving , The difficulty is how to make sure that there is no repetition or omission . These details are solved by programming implementation and experience .

Whether it's process oriented or object-oriented , The difficulty of realizing the above functions is the same . The parsing function of string is recommended C Of language base strtok function ,

#include <string.h>
#include <stdio.h>
 
int main () {
   char str[80] = "This is - www.runoob.com - website";
   const char s[2] = "-";
   char *token;
   
   /*  Get the first substring  */
   token = strtok(str, s);
   
   /*  Continue to get other substrings  */
   while( token != NULL ) {
      printf( "%s\n", token );
    
      token = strtok(NULL, s);
   }
   
   return(0);
}

Running results ：

This is 
 www.runoob.com 
 website

Very convenient and easy to use , However, pay attention to the pointer array and don't cross the boundary , otherwise hardfault It's also annoying .