Two days ago I made a mistake, do not blame yourself seriously, a small problem to tinker with one week only to find the reason. This type of online description of the error is relatively small (PS: may be too low, and we disdain to describe, laughed ha ~), recorded here, give newcomers mind you, but also to their legislation a flag.
1. What happened was this (problem background):
At that time the category of serial download files to QT embedded board, sent by the normal data does not match the received data length, it is generally more; QT receive data sent by serial debugging assistant, found that really is not the length of it, and not the law. Because it is the first time for download here, for encoding the data stream are not very understanding, so seize the time catching up. Find a variety of reasons, various test, various modifications coding, no effect ~ hey look ignorant of force. . . .
2. stumbled extra byte (phenomenon lock):
More out of the wisdom of it? I wondered. At that time the source of the data is obtained from the binary file, read out, and then dump QByteArra. To lock problem, reduce the length of the file to read, find the extra bytes. Ah, found, it is "0A".
QTextCodec::setCodecForLocale(QTextCodec::codecForName("GB2312"));
readDataArray = binFile->read(packHead[packLen].value);
3. Further exploration:
Windows will be added at the end of a file / r / n, converted into 16 hex, is 0D 0A, 0D front each have one more 0D, really strange ah. Whether these binary files which can be some did not, because there is a .bin file data Yeah, 0D and 0A are likely to be data itself. A closer look and found the individual will add 0D 0A in front. This. . .
4. Comparison of someone's home:
I found a few other people QT serial debugging assistant, read the source code, it seems very simple, but to send everything is normal. Thus began a series of QT serial port configuration information, and is configured to find the cause. Later discovered that the goods:
serialPort->setTextModeEnabled(true);
Here is a setTextModeEnabled, others have not, I have. The rush to look up doing. QT help in says so:
void QIODevice::setTextModeEnabled(bool enabled) If enabled is true, this function sets the Text flag on the device; otherwise the Text flag is removed. This feature is useful for classes that provide custom end-of-line handling on a QIODevice. The IO device should be opened before calling this function.
Not embarrassing?
5. recurring phenomenon, to determine the cause:
Originally a normal serial code is transmitted "00 02 0d 0a", it is really more of a 0d received.
00 02 0D 0D 0A[2019-12-30 05:08:34.742] 00 02 0D 0D 0A[2019-12-30 05:08:34.912] 00 02 0D 0D 0A[2019-12-30 05:08:35.108] 00 02 0D 0D 0A[2019-12-30 05:08:35.305] 00 02 0D 0D 0A[2019-12-30 05:08:35.486] 00 02 0D 0D 0A[2019-12-30 05:08:35.678] 00 02 0D 0D 0A[2019-12-30 05:08:35.860] 00 02 0D 0D 0A[2019-12-30 05:08:36.041] 00 02 0D 0D 0A[2019-12-30 05:08:36.222] 00 02 0D 0D 0A[2019-12-30 05:08:36.393] 00 02 0D 0D 0A[2019-12-30 05:08:36.586] 00 02 0D 0D 0A[2019-12-30 05:08:36.780] 00 02 0D 0D 0A[2019-12-30 05:08:36.958] 00 02 0D 0D 0A[2019-12-30 05:08:37.150] 00 02 0D 0D 0A[2019-12-30 05:08:37.342] 00 02 0D 0D 0A[2019-12-30 05:08:37.523] 00 02 0D 0D 0A[2019-12-30 05:08:37.716] 00 02 0D 0D 0A[2019-12-30 05:08:37.896] 00 02 0D 0D 0A[2019-12-30 05:08:38.089] 00 02 0D 0D 0A[2019-12-30 05:08:38.572]
summary of the issue:
setTextModeEnabled (true) means that the device is opened in Text mode, when reading, the line terminator is converted into \ n-, it will cause transmission problems.
