@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.

There's one other thing that is strange, the documentation of netcat explicitly state that you should not use -p and -l together. So what exactly are you connecting to ?

@VRonin
Server is on a different machine in the LAN and the software is not from me.
I only implement the client side.

@Basti46
Good work!
:)

@Wieland
Thank you so much, Wieland. You're 100% right, and I was not lucky enough :)
After moving the sending of finish signal elsewhere, everything goes fine.

You can use two different slots or use the same slot but check what the sender is (you get pointer to the sender calling sender() in the slot).

@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...

#2 is wasteful way indeed!
but in low baud rates it will help, but in this case I don't think this is a low baud rate.

EDIT : I said for example 1ms, you really don't need it this fast, it depends on the frequency of getting bytes, for example for 20Hz you will have 20bytes every second which means you need a timer with at least 50ms refresh time and of course you read from serial port in asynchronous way then you can't 100% trust this way to read byte by byte, So as @JKSH said you better don't use this way if you don't have a specific reason.