Ok, that's how I understand it now (again, please correct me if I'm wrong):
In a single-threaded program the slots connected to emitted signals are executed immediately, whatever the Qt::ConnectionType is.
If it happens that signals are emitted simultaneously, they are written in a thread event queue and corresponding slots are processed one after another (even if these signals are connected to the same slot).
@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.
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.
@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.
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.
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.
Just to confirm that QSerialPort can be used on rooted Android. (Some info)
/* This will open the Superuser app,
* prompting for root permisions
proc.start("su -c \"chmod 666 /dev/ttyUSB0\"");
Don't forget to disable SELinux on Android 4.2 and above :)
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.
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!
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...
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!
@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!
Thank you for the idea. Yes, writing a wrapper class around the serial port worked like a charm. I implemented it a bit differently, a message handler manages the message building and sending it off to the serial port but the concept is the same. The only thing I found different from your example is that the timer isn't destroyed when it runs out. Instead of creating a new one every time, I created one as part of the class and use it over and over again.
This will put your thread to sleep until data has arrived or 200 ms has elapsed. QSerialPort seems to rely on the message loop to handle data so this might interfere with it (?). There is no guarantee that you will have 512 bytes of data back at once either.
There is a signal (QSerialPort::readyRead() ) you can use when received data arrives. Connect this to a suitable slot and buffer what has arrived each time the signal is fired (I assume you will not get all the data at once). Do this until you have 512 bytes then process it. Keep the event loop active if you have some other 'heavy' function somewhere (QApplication::processEvents() ).
I am sorry about my last post. I made a stupid error. I updatet to QT5.5, but I haven't reconfigurated the project, so I was still using QT5.4.
Now I tried also the Chipi-X10 USB-RS converters. I have to say, they work a lot better. I have now for all three ports, this converter. With the others, a lot of times I had to unplug and replug the connectors to get dem work. So there is something strange. The Chipi worked really good until now, thank you jeroen3, this will save a lot of time.
After building the programm with QT5.5, the programm also work a lot better. I saw that the qcustemplot keeps plotting while I drag and drop the window. I have sometimes errors but now only sporadic. For example when I resize the window very fast, I can provoke it. But in general the errorrate is about one or two percent, and with that I can live.
PS: We here do not play in telepathists and predictors. If you want to get help, you should provide the minimal and simple example....
My problem was, that with the minimal simple example all seems to working. This communication problem I had only, wenn all the data was coming and when I was plotting someting in the same time. And I checked my code a lot of times. The problem is, my knowhow about QT and generell about programming with PCs is not very big. So I think there is something I do not know. So when I check my code a hundet times more, I will not find an error.
I made also an easy experiment to isolate the error:
My I slowed up the replot, so that I plot only every tenth time, but ten points at the same time. Like this I can see, that this error, comes only when the window is plotting. The error comes more, the more points he has to plot on the screen. So if I make fullscreen, and I set up the scale so that I have the maximum of points in the axis, the error comes every time again.
So QT has an influence to this problem. I think there is an overflow in some buffer, beause the program is to slow to read it or that he overwrites any part for some other reasons. But anyway.. For me I will pay attention now to not overcharge my comuter :)
Thank you for all help!