Character encoding problem with QextSerialPort (Qt/C++)

I am developing a Qt/C++ programme in QtCreator that reads and writes from/to the serial port using QextSerialPort. My programme sends commands to a Rhino Mark IV controller and must read the response of those commands (just in case they produce any response). My development and deployment platform is Windows XP Professional.

When the Mark IV sends a response to a command and my programme reads that response from the serial port buffer, the data are not properly encoded; my programme does not seem to get plain ASCII data. For example, when the Mark IV sends an ASCII "0" (decimal 48) followed by a carriage return (decimal 13), my buffer (char *) gets -80 and 13. Characters are not properly encoded, but carriage returns are indeed. I have tried using both read (char *data, qint64 maxSize) and readAll ().

I have been monitoring the serial port traffic using two monitors that interpret ASCII data and display the corresponding characters, and the data sent in both ways seem to be correctly encoded (they are actually displayed correctly). Given that QByteArray does not interpret any character encoding and that I have tried using both read (char *data, qint64 maxSize) and readAll (), I have discarded that the problem may be caused by Qt. However, I am not sure if the problem is caused by QextSerialPort, because my programme send (writes) data properly, but does not read the correct bytes.

I have also tried talking to the Mark IV controller by hand using HyperTerminal, and the communication takes place correctly, too. I set up the conne开发者_高级运维ction using HyperTerminal with the following parammeters:

• Baud rate: 9600
• Data bits: 8
• Parity bits: 0
• Stop bits: 1
• Flow control: Hardware

My programme sets up the serial port using the same parammeters. HyperTerminal works, my programme does not.

I started using QextSerialPort 1.1 from qextserialport.sourceforge.net and then tried with the latest source code from QextSerialPort on Google Code, and the problem remains.

What is causing the wrong character encoding?

What do I have to do to solve this issue?

48 vs. -80 smells like a signed char vs. unsigned char mismatch to me. Try with explicit unsigned char* instead of char*.

Finally, I have realized that I was not configuring the serial port correctly, as suggested by Judge Maygarden. I did not find that information in the device's manual, but in the manual of a software product developed for that device.

The correct way to set up the serial port for connecting to the Mark IV controller is to set

• Baud rate: 9600
• Data bits: 7
• Parity: even
• Stop bits: 2 bits
• Flow control: Hardware

However, I am still wondering why did HyperTerminal show the characters properly even with the wrong configuration.