End QSerialPort open attempt on timeout
-
@Dummie1138 My feeling is that you are looking for your keys where there is light and not where you lost them.
That time-out, which isn't all that high for a connection (network, wifi, bluetooth, etc.) is probably not due to the serial but to the bluetooth serial conversion.
My advice is that it's okay, or either to investigate the conversion, or to try on a real com port.
@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? -
@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.
