@Narutoblaze
Your code/algorithm is incorrect. This is basic coding, please study what your code does. You "actively" encourage reading across file boundaries, i.e. what you call "too much").

You (seem to) start by setting size to the total number of bytes expected for the file. Then you call read(buffer, size);. But when that returns with fewer bytes than size you still call it again next time round asking it to read up to size further bytes. This can/will exceed the number of bytes in the first file. You obviously need to reduce what size you pass to read() accordingly on subsequent calls. And then be careful what you compare in your if (... || numReadTotal == size). Adjust your code however to make it right.

I previously said that the whole synchronous approach of repeatedly calling waitForReadyRead() in a loop is not the event-driven way to do things. Allow bytes to arrive in repeated readyRead() signals asynchronously instead.

@JonB @mrjj

It's coming back to me. I once had the same problem with an IMU sensor that I could not solve under windows.

But once under linux with the same code, I receive the data perfectly.

Same thing, I just tested under linux for the GPS, I receive the data but not under Windows.

To this day I don't know where the problem comes from

@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

@VRonin said in problem with QLocalSocket sending continues data to QLocalServer:

This is not correct.

Damn, and sorry! I thought that it had said that, but not. I may have confused with

readyRead() is not emitted recursively; if you reenter the event loop or call waitForReadyRead() inside a slot connected to the readyRead() signal, the signal will not be reemitted (although waitForReadyRead() may still return true).

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