The data length instability problem of QT serial port receiving

Recently in a real-time receive data project, need every 2ms receive the next two frames of data, is a serial port high-speed reception.

In the use of the process, found that the serial port received data length is not stable, sometimes long and sometimes short.

The code is as follows:

Connect (serial,signal (Readyread ()), This,slot (Serial_receive ()));

And then in the slot function.

Serial->read (All);

found that the data read far more than two frames, so instead of

Serial->read (2);

The data read is still unstable, for example, the data I want is 0x02,0xff. Sometimes it is 0x02,0x00 to read it.

This problem, from the online Baidu, most people's description is that the Readyread function is not every time a data on the trigger, but an indefinite number of triggers, so as to cause the problem, so that the data length of each read is different.

After my thinking, I think the reason is not so, the Readyread function is really a receive data will trigger the slot function, and the data length is not stable because the serial port receives the data and will not wait for you to continue to receive the slot function after processing, It is possible that when you enter the slot function, the serial port will receive a number of data (this will appear in the case of high-speed reception, and I do not think that the trigger slot function at this time, the principle should be and can not interrupt nesting almost), then if the use of ReadAll, the length of the reception is naturally unstable, There is no guarantee that the serial port in this period of time to receive the number of data, which explains why I use Read (2) will appear after the data of 00, because the Readready trigger condition is to receive a data, and I read two, I cannot guarantee that the serial port can receive the next data in such a short period of time, but the experimental results prove that most of the time is possible, but there will be about 30% of the probability that I read the action ahead of the action received, so there is the data behind the 0 case.

Practical solution: Using a circular linked list, to determine the packet end of Baotou