End QSerialPort open attempt on timeout
-
@giusdbg
Not my area of expertise. But what time-out are you talking about? The OP's timings show that it takes 7 seconds forQSerialPort::open()to return when, apparently, there is no device attached on the port. And during that time the code is blocked on that call. Is this normal? Would I, as a user, expect open serial port to take 7 seconds when nothing is there, and would I care that the UI will be blocked during this period?@JonB open should be a blocking instand call and return. The OS should respond super quickly when the port can't be opened on request.
I have never, ever - in now 10 years - had the situation where open would not return immediately. Maybe once, where the complete OS crashed shortly after. But I also never had a Serial Over bluetooth link. Bluetooth handshake and service exchange does take a significant amount of time and may be the culprit here.
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@JonB open should be a blocking instand call and return. The OS should respond super quickly when the port can't be opened on request.
I have never, ever - in now 10 years - had the situation where open would not return immediately. Maybe once, where the complete OS crashed shortly after. But I also never had a Serial Over bluetooth link. Bluetooth handshake and service exchange does take a significant amount of time and may be the culprit here.
@J-Hilk
Can you give the OP a command outside of his Qt program to show if the OS is taking a long time to open the port (so it's not a Qt issue)? For example, this might not work, but from a Command Prompt can you perhaps go something likecopy COM10 nuland see that wait 7 seconds till it finishes? -
@J-Hilk
Can you give the OP a command outside of his Qt program to show if the OS is taking a long time to open the port (so it's not a Qt issue)? For example, this might not work, but from a Command Prompt can you perhaps go something likecopy COM10 nuland see that wait 7 seconds till it finishes?@JonB you would need Putty or Hyperterminal or something similar and then the command depends on what the op chooses
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@JonB you would need Putty or Hyperterminal or something similar and then the command depends on what the op chooses
@J-Hilk So, the way forward should be to test the COM port with a terminal to try and send data through? Or just test connections?
-
@J-Hilk So, the way forward should be to test the COM port with a terminal to try and send data through? Or just test connections?
@Dummie1138 yes, see if you also run into those timing issues with other already completed programs, I would also suggest updating drivers sometimes that fixes this too
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@giusdbg
Not my area of expertise. But what time-out are you talking about? The OP's timings show that it takes 7 seconds forQSerialPort::open()to return when, apparently, there is no device attached on the port. And during that time the code is blocked on that call. Is this normal? Would I, as a user, expect open serial port to take 7 seconds when nothing is there, and would I care that the UI will be blocked during this period?@JonB Those are not normal serial, they are bluethooth <-> serial converters (usually they are ethernet <-> serial).
When the serial port is opened, a series of conversion/connection operations are performed, which usually require a long timeout.
A test with Hyperterminal is a good idea
-
@Dummie1138 yes, see if you also run into those timing issues with other already completed programs, I would also suggest updating drivers sometimes that fixes this too
@J-Hilk I see. I shall do that then, thank you. However, I would still like to have a timeout for the serial port in case external users do not update their drivers and have bluetooth connections which take a long time. Would it be possible?
-
@J-Hilk I see. I shall do that then, thank you. However, I would still like to have a timeout for the serial port in case external users do not update their drivers and have bluetooth connections which take a long time. Would it be possible?
@Dummie1138 said in End QSerialPort open attempt on timeout:
Would it be possible?
In principle... yes. You could hook a timer to an interrupt or move your serialport in a thread and forcefully delete the QSerialPort instance while it's still busy with system calls.
That may or may not work and in general I would advice against it.
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@Dummie1138 said in End QSerialPort open attempt on timeout:
Would it be possible?
In principle... yes. You could hook a timer to an interrupt or move your serialport in a thread and forcefully delete the QSerialPort instance while it's still busy with system calls.
That may or may not work and in general I would advice against it.
@J-Hilk What would be the issues that come form this approach?
-
@J-Hilk I see. I shall do that then, thank you. However, I would still like to have a timeout for the serial port in case external users do not update their drivers and have bluetooth connections which take a long time. Would it be possible?
@Dummie1138
You might move the serial port to a thread and do theopen()there. (I believe you can move it back to another thread if you want.) That would mean the call would only block that thread, not the UI.(Personally) I would not try to destroy the port object while it is executing an
open(). It probably won't abort it anyway, and likely leave things in a bad state.
