How did you install Qt ?

@tangxinzhou I'm afraid I do not have a solid solutions. I'm running a workaround now. Let me post it for you: void connectDevice(bool connect) { if(connect){ switch (mDevice->state()) { case QModbusDevice::ClosingState: case QModbusDevice::ConnectedState: case QModbusDevice::ConnectingState: mDevice->deleteLater(); mDevice = new QModbusRtuSerialMaster(this); setupSignalSlots(); QTimer::singleShot(100,this, [=]{setConnectParamter(m_port,m_paramter);}); break; case QModbusDevice::UnconnectedState: default: if(!mDevice->connectDevice()){ emit signalModbusError(mDevice->errorString()); mDevice->disconnectDevice(); } break; } }else{ stopPoll(); mDevice->disconnectDevice(); QTimer::singleShot(200,this,[=]{checkDisconnected();}); } } void checkDisconnected() { if(mDevice->state() != QModbusDevice::UnconnectedState){ mDevice->deleteLater(); mDevice = new QModbusRtuSerialMaster(this); setupSignalSlots(); } }

@AngrySkarpeta Well it might be overkill but it´sounds like its not really connected but without actual errors then its not possible to guess at all. Could be a driver issue or trust issue. You should use other tools to try to test if they are really paired.

@QtExchange said in Segmentation fault or overflow when streaming from a QSerialPort: The trick is one QByteArray receives the data (on signal slot basis) QByteArray can receive nothing, it's an array of bytes - a container, nothing more, nothing less. where the other container (which is just a copy of the receiver-QByteArray) is parsing the received Data, as the symbols come in a random order. ??! How can you parse something that doesn't have any order? And where is this other container? I could think of having an extra signal-slot that exchanges the data between both containers whenever it is demanded, but it sounds like I have to double check if I'm actually dealing with the most current data. I don't follow. Why would be this even needed ...? There's an extra mutex for the device access, and another one for the shared message container. Qt imposes thread affinity on QObject instances, you don't need a mutex for device access, and you shouldn't share the message container. and because I'm dealing with QElapsedTimer, that needs the thread. In what universe QElapsedTimer needs a thread ...?! It's like saying that an integer needs a thread ... I don't get it.

It is not a qserialport issue, it is a kernel/driver issue. A driver of your serial port has bugs, you should try to update driver or to use another HW device.

@cdcc0606 Typical, can you upgrade to 5.3?

Hi, What about reading the whole buffer and then search for the first occurrence of '\r' ? That way you avoid to loop on the input

@Basti46 Good work! :)

Just to confirm that QSerialPort can be used on rooted Android. (Some info) Notes: #ifdef Q_OS_ANDROID /* This will open the Superuser app, * prompting for root permisions */ QProcess proc(&a); proc.start("su -c \"chmod 666 /dev/ttyUSB0\""); #endif Don't forget to disable SELinux on Android 4.2 and above :)

I figured out, it was nescessary to set DTR: port.setDataTerminalReady(true); Thanks & br, Clemens

So does the QT appends '\0' terminator after every append? ( For QByteArray - No.

Getting back to document conclusions of my research on best practice of using RaspiComm RS-485 under Qt for anybody, who finds this thread useful (I expect many of it is valid for RS-232 on same board as well, did not test myself): Do not try to implement communication with MAX3140 UART chip yourself (maybe except of asm based implementation, what is however most probably unnecessary exertion). I succeeded to implement it based on kernel /dev/spidev0.0 only to find out that even this partially system driver supported solution is too slow for even 19 200 Bd speed (loosing about 5 characters on one received). I myself feared about RaspiComm RS-485 driver /dev/ttyRPC0 based on some forums complaints and not clear versioning, however found out, that the forum thread was heavy outdated. These official installation instructions worked like a charm and the resulting driver worked out-of-box for my latest Raspbian Wheezy (4.1.7+ #817). So I strongly recommend to take this approach. QSerialPort class has constructor with signature QSerialPort(const QString &, QObject *), where QString may contain even device which is not included in the QList that QSerialPortInfo::availablePorts() returns. This works with no surprise. If one does not set anything than (eventually) baud speed, one gets standard 8 bit, 1 stop bit, no parity without any character translations, good old plain raw binary. So QSerialPort may be used with /dev/ttyRPC0 directly and easily. QSerialPort rpc0("/dev/ttyRPC0"); rpc0.write("Binary request\0even\xffcontaining weird\x03characters", length_of_binary); if(rpc0.waitForReadyRead(100)) // Enough long time in miliseconds QByteArray data = rpc0.readAll(); // You may have to wait/read repetitively in loop // and merge data on higher link speeds Hardware of RaspiComm uses RTS pin to select in/out direction of data. CTS is kept active permanently by wiring, so using default use RTS/CTS mode works properly with no inappropriate blocking. That's all you should need, so enjoy your communication.

@kuzulis: Thanks for the hint to update to 5.6.0! Since it is some effort to update the embedded installation on the Qt target, I first tried the terminal example with 5.3.2, just adding /dev/ttyGS0 as a serial interface manually. Interestingly, transmission worked very well even after re-loading the g_serial driver. So i had a look at my own qt program, again. First, very strangely, transmission didn't work at all, but after restarting the embedded system, doing a "clean all" on the project and built it again, everything now works perfectly also in my program... Very strange... So I hope there has only happened something in the build directory and now everything is solved doing the clean and re-building... Everybody, thanks a lot for your help! Greetings, Markus PS: I also had to update my desktop qt installation for receiving the terminal example files (didn't find the bundled files on the qt site and my installation didn't provide them, also), but I guess this didn't have an effect on my cross-compiled application...

Just for the community to know, the problem was on the firmware of the integrated J-Link OB-SAM3U128. Latest firmware upgrades bring this known bug with QSerialPort on windows. More information can be found here: [http://forum.segger.com/index.php?page=Thread&postID=8772](link url) I fixed the problem downgrading the segger firmware to the 2014 Nov 28 10:32. To do that, uninstall the segger application and drivers and install an older version you can find in the website. For me worked the version 496g. To downgrade the firmware before you have to invalidate it: with the jlink commander execute "exec InvalidateFW" and then, from the jlink configurator replace with the current host version (right click on the emulator raw -> replace firmware). Hope this could save a few working hours to someone. If anyone managed to found better work-arounds, please post them here!

Ok, even i tried copying by libraries to the deploying system, and exported it , then binary will execute, but serial port will not work as in the code.,

I didn't saw that there was no tooltip for them… At least there is for the flag and quote :) Thanks :)

@Rondog @kuzulis I'm going to give the bytesWritten()signal a try, I will let you know how it worked out. I don't have a separate thread set up, but it's definitely worth the try! Big thanks for the reply's!

There are a few options. char c; while(port.read(&c,1) > 0) // returns the number of char's read, -1 on error { if(c) { // 'c' does not contain null. do something with it } }; or maybe something like this QByteArray data; data = port.readAll(); // QByteArray & QByteArray::replace(char before, const QByteArray & after) data.replace(char(0x00),QByteArray());

Yes, i made this program by the terminal example. I solve it. I use QStringList to delete the first response. But, i thank you for for answer.