Unsolved Send a serial message before closing the serial port in Qt
-
@Chicowolf said in Send a serial message before closing the serial port in Qt:
how should i use it?
I don't understand - simply call it? QSerialPort is derived from QIODevice...
-
@Christian-Ehrlicher ok, i tryed to call it before and after the write call, but the issue persists
this is the message received by the device: as you can see, it's a random message of 4 bytes instead of the 8 byte message i sent -
Are you using windows? Which Qt version exactly? waitForBytesWritten() + flush() should work for sure.
-
Yes, i'm using windows and Qt 5.14.1
This is my code nowdevice->flush(); device->write(QString("DISCONCT").toStdString().c_str()); device->flush(); if(device->waitForBytesWritten(30000)) { displayMessage("Disconnected"); deviceIsConnected = false; device->close(); ui->PortComboBox->setEnabled(true); ui->tabWidget->setEnabled(false); ui->ConnectButton->setText("Connect"); ui->ConnectionStatus->setText("<span style=\" color:#e1d41f;\">DISCONNECTED</span>"); }
-
What is your state machine for the microcontroller? What is it suppose to do when it receives "DISCONCT"? Does it expect that the command be newline terminated? Can you sample a GPIO on the microcontroller when it receives the DISCONCT? Your problem may be on the embedded component and not in the Qt logic of "send and wait"....but without seeing the controller program I don't know how you're parsing the incoming command either.
-
The state of the microcontroller is "CONNECTED" since the program sends the message "HELLO___" to the micro. When it receives "DISCONCT" it goes to "IDLE" state, ready to reconnect again if needed. It doesn't expect any '\n' character. I could use an oscilloscope, but it doesn't have the UART decoder fuction built-in; i'm monitoring the internal variables though, thanks to the debug mode in the micro, and i'm pretty sure that the issue is related to the close() call, since if i comment that call, the message is received.
As you can see in the image i posted in the previous answer, the micro's variable "RxData" it's not filled with the "DISCONCT" word, but with 4 random character.To be fair, with the waitForBytesWritten(30000) call, the program doesn't seem that it waits for 30 second, it seems pretty responsive instead. If necessary i could post the entire code.
-
If you're already Debugging the Qt code then make some breakpoints inside qserialport_win.cpp in the close() and waitForBytesWritten methods.
-
@Christian-Ehrlicher thank for the suggestion :)
I made 3 breakpoints in the write(), waitForBytesWritten() and close() calls. The message is sent without problems, but after the flush() call, not after the write() call; the waitForBytesWritten(30000) call, doesn't wait for 30 seconds, but the close() call works as expectet.
Now that i put these three breakpoints the program seems to work fine, even in non-debug mode. I don't understand what is going on :/ -
There are no any way to know that a data has been written to the physical line.
A best way is wait for a device response (e.g. ACK) and only then close the port. Other way is just use QSP::bytesWritten() signal, and after this signal received wait a bit using QTimer with some empiric timeout (e.g. with some milliseconds), and only then close the port.
-
I'm sorry to say it, but I'm leaning toward a questionable protocol on the embedded board. You are trying to parse block commands from a stream data feed. There are oh so many potential problems by not using either 1) all fixed length commands, or 2) choosing and consistently using an end of message indicator like \n...and consistently sending a status indicator upon receipt and processing of EVERY COMMAND.