Thanks for your feedback.
I have identified that the problem is due to the EDBG chip (usb-serial bridge) which requires DTR signal to enable the serial port RXD and TXD pins.
Including the line of code "serial->setDataTerminalReady(true);" after opening the serial port, the serial port application is now working fine. I guess this is automatically carried out on hyper-terminal software and tera-term software.
Whether the communication uses the flow control or not,some of the hardware bridge requires the flow control signals to be set for the first time after power ON.
The overlapped mode is the problem. If you only have a handle then ReadFile / WriteFile will fail if you don't include the overlapped structure in the call. It was opened with the OVERLAPPED flag so this parameter cannot be NULL.
What exactly are you trying to do? Maybe there is another way.
@Wieland, this float number is represent the speed Value of DC motor in RPM, may you mean I it should be in double type or something else!!.
in fact I don't know obviously whit's the type I should use this is the GUI I built link text
you can see in Stack-overflow here: link text
may you get what I need, I'am sory to be annoying but I spent alot of time in this problem :(
I am also trying to write a minimal qml app that uses the built in GPS to retrieve current position. I am not sure if I can use Qt positioning or if I should just parse the raw output of the GPS myself, like the OP did here, and extract the position manually. It seems very dirty to do it that way, I thought there would be a nice API in QML that I could use. Anyone can point to a simple example?
HI and welcome
The signal readyRead (serialReceived) is sent when QSerialPort reads some data.
Try to not call serial->write("1",1); in your serialReceived
as it might make controller send more data and it might never get out of there.
(end less loop) as its called pretty fast.
Else they code seems fine.
QByteArray data.append( serial->readAll());
(and move QByteArray data to MainWindow.h)
and then when data.size() == 8 then
@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!
Thanks for your reply...
I agree that may be my code is not the best practice, as i learn Qt by myself only with doc and tutorials... but the program was working perfectly when i delivered it to the researchers... In fact, is working perfectly if i compile it on windows... few hour ago i borrowed a windows machine, installed qt, compiled the same project and worked just fine... So i doubt is really a code problem, because it should appear in both Windows and Linux, as the code is exactly the same...
I'm starting to think that is a linux driver problem, so i will try in another linux when i get the chance...
If someone has ubuntu 15.04 and is kind enough to reproduce this problem and tell me i would be very happy!
If anybody else reproduce this problem in other linux machine i will start a bug report
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!
With Qextserialport, around 4% of the bytes get dropped at 115200 baud. On decreasing the speed to 9600, data reception is much better. Only issue is that of the initial 160-190 bytes that are received, some bytes are missing. After the initial 190 bytes, there is no loss at all. Since the loss seems to be predictable, I plan to append some known value 200 times ahead of the actual data and send the whole sequence. The known value will be neglected at the receiver end in software.
Hello, everyone. After some hours of debugging, I could finally find the problem. Long story short: apparently, the Linux driver for CP210x USB-TTL converter does not implement software flow control, but only hardware flow control. I've moved to the latter and it's working like a charm now. Thank you all for your help.