The issue was that it had to be byte \x05 and QByteArray.setnum(5) will result in \x35 so I had to use QByteArray::append()

Here the bug report for this issue: https://bugreports.qt.io/browse/QTBUG-78086

@elypheldia said in How I listen serial port with writing client code?: Sorry if used the wrong term. I am new on qt. I wanted to indicate that I read the data I wrote to the tnt0 serial port from terminal with using cat /dev/tnt0. But How can I do this with client code instead of reading from terminal. I just wanna open the tnt1 serial port from code., and I wanna read from there. You are confusing to me. Do you want to use /dev/tnt0 or /dev/tnt1? With the code example you have provided, you are writing hello on serial device /dev/tnt0. Is this working? You have defined a slot MySerialPort::readData() , which is called when data are ready to be read from serial port. I have proposed you some changes to display debug message when slot is called. Is this slot called? I don't know: what kind of device is connected to this serial port? if the serial port configuration is correct according to attached device? the attached device communication protocol: It is a binary or text protocol? Are carriage return or line feed required?

@J-Hilk Thank you all guys for your patient and sorry for my basic mistakes :). I fixed my issue. As you said, I expect the read without writing a data to serial port.

@Tague-Carlyon the event loop of QCoreApplications needs to be running, otherwise this won't work at all.

Ok well here's an interesting discovery I've made, for anyone who finds this thread in the future: There seems to be an issue with the driver for the off-brand Arduino Nanos possibly not signalling to the OS correctly, or the implementation that Qt uses just really doesn't like the way that the driver responds. I am referring specifically to the nano clone which uses the QinHeng HL-340 serial peripheral. Not sure why this caused a problem, but there it is. Once I used an official Uno the code worked no problem. If I were more patient and had better resources I could possibly trace back the issue, but I do not, so sorry everyone lol. As such I'm marking this as resolved.

@SGaist That's precisely the idea! :)

Повесь сигнал готовности порта к приему данных на слот приема данных: connect(&serial, SIGNAL(readyRead()),this,SLOT(ReadFromPort())); void ReadFromPort(){ QByteArray data; data.append(thisPort.readAll()); qDebug() << data; } Я вообще юзал порт в другом потоке: http://we.easyelectronics.ru/electro-and-pc/qthread-qserialport-krutim-v-otdelnom-potoke-rabotu-s-som-portom.html

@BurSer if your issue is solved please don't forget to mark your post as such!

@IRBaboon If your PC have no obvious lagging, my issue is an error direction. Here are some ideas you can try: read help doc seriously or test one other poeple's credible demo on your devie, is it possible to call it incorrectly?(for serial device, It is difficult for others to run your demo) try the lastest verion of QT

Here's my solution for this, in case anyone's interested: The header file: #include <windows.h> #include <dbt.h> #include <QObject> #include <QAbstractNativeEventFilter> class DeviceEventFilter: public QObject, public QAbstractNativeEventFilter { Q_OBJECT public: DeviceEventFilter(QObject *parent); bool nativeEventFilter(const QByteArray &eventType, void *message, long *result) Q_DECL_OVERRIDE; Q_SIGNALS: void notify(); }; And the source file: #include "eventfilter.h" DeviceEventFilter::DeviceEventFilter(QObject *parent) { Q_UNUSED(parent) } bool DeviceEventFilter::nativeEventFilter(const QByteArray &eventType, void *message, long *result) { Q_UNUSED(eventType) // unneeded as long as we're only running on Windows Q_UNUSED(result) MSG *msg = (MSG *)(message); if ((msg->message == WM_DEVICECHANGE) && (msg->wParam == DBT_DEVNODES_CHANGED)) { emit notify(); } return false; }

Sounds like you should not be using QSerial and instead design a custom solution outside of Qt. Qt is not for real-time processing and your description of the task seems to imply real-time constraints.

Thank you, the problem was, that I didn't wait for the Bytes to be written.

@hskoglund thanks for the help! I did not try your solution, but I guess it should work because the solution from @KroMignon works and you have the same diagnostic.

@J-Hilk Tks, I will do a test. Btw, I want to know more the root cause of QSerialport did not emit readyRead () signal.

Hi and welcome to devnet, This is a known issue: QTBUG-78086. It's fixed and will be part of Qt 5.12.6 and 5.13.2.

Few place I read, it is generated due to some issue with kernel. So I just update the Ubuntu LTS, and Now it is working with same code.

yup looks like it is that bug, thanks guys

@kent-dorfman Flow control is not implemented on this receiver. GPSD is also not a concern as this receiver does not speak NMEA it conforms to ICD-GPS-153c.

@fcarney You were right. I changed the line where I initialize the serialport to a position before the connect and that works. Thanks!

@Kent-Dorfman Out of curiosity, and not wanting to start a flame war, I'm slightly surprised that you ship I/O access out-of-process. It may well be convenient for debugging/testing, but for production? Then again I know nothing about hardware, so you may so that serial port top speed is slow it doesn't matter, I don't know....

@Dooham You're OK, you are not the first (or the last) here to ask/state this! :)

@smnsmn said in Connecting several readyRead() signals to one slot (QSerialPort): Qt::QueuedConnection The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread. This is for queued connections which are not used by default for signals/slots in same thread. You really need to differentiate between connections in same thread and such between different threads. "Can signal thread == receiver thread?" - sure, it is like this most of the time. Only if you use more than one thread you can have signals and slots in different threads. For signals and slots in same thread queued connection is NOT used, unless you tell Qt to do so (last parameter in connect() call).

@Christian-Ehrlicher Thanks, that was exactly my problem.

@aha_1980 I'm expecting to read and write data with a serial port, but, for some reason, the data sent by my pc is also read by my pc, so the problems is that the data sent is somehow triggering the readyRead signals. @J-Hilk I noticed that ,effectively, the echo wasn't turned off on the pi. For whatever reason, it completely broke my programs when I'm turning it of, so I'm going to install qt and try again on the pi before calling it a win.

@kuzulis I installed com0com and have written a sender, but the behaviour is completely different and I can't reproduce the problem. The sent datablocks are received in the same size (up to 4096bytes) and the same time independent of the blocksize and speed I use to send the data. I don't think this approach helps... PS: The errorOccurred is handled and I doen't get an error. I commented it out for using QT5.7

@dheerendra At this point, we are fairly certain that the problem is in the main thread code. I have uploaded the main thread code in the previous comment. Please suggest any necessary changes that could solve the issue. thank you.

@sykac said in Turning off power to a running QSerialPort: One problem starts probably in the hardware. The COM port of the device disconnects from the PC (I don't why, it could be some driver/firmware issue) Reading you topic title, could it be that the USB connection between PC and FTDI is interrupted? And that's what I said, this may lead to endless loops in the device driver. This kind of problems can hardly be solved in the user space.

I agree you need to use a state machine for that case. http://doc.qt.io/qt-5/qstatemachine.html probably helps putting down the skeleton already

Please try while (true) { if (SerialPort.waitForReadyRead(100)) { while (SerialPort.canReadLine()) qDebug() << SerialPort.readLine(); } } Now you can work on the already ready buffer obtained from "SerialPort.readLine();"

@cesar93 so if your problem is solved, please mark this topic as SOLVED too. Thanks

Solved. The missing libQt5SerialPort.so.5 error on the target device was because that library effectively was not present. On the host side I added that library in the package list of the image and rebuild the image itself.

@kuzulis Thank you. It works perfectly now :-) TLDR: My mistake was to not instantiate and open the QSerialPort in the thread i was reading from.

@aha_1980 Thank you so much for your ideas. Both problems solved. After reconfiguring aptitude stuff to use "stable" instead of hard-coded "jessie" and half-a-day-long upgrades and cleaning the mess I really got not only higher version of Qt, but as well QParallelPort working as planned. Definitely worth the effort (even if I did not expect the upgrade to take so much time.) My mistake. I missed this single character overload to append(). Thank you for pointing me there. Now I got completely rid of that development/release conditionals. Case closed, thanks to all who assisted.

Hi, You can get the native handle with QSerialPort::handle and then modify its properties. Hope it helps

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.