Dear Rolf @rkl099,
Thanks again for great SerialOTG extension and support.
I run into a problem:
Connect is synchronous which blocks any user interaction - I tried to workaround it by calling it in background task which kind-of works - except when I switch screens because the Async extension I use does not stop that subprocess when I change screen and on new screen it results in an error.
Yr timeout is much less the built-in BT but still is a hassle for my users.
Is there a way to call it in non-blocking way (asynchronously) but is the same time canceling it when I change screens?
I have continued to revise the code. In this driver I found a busy loop, that waits for the transmit buffer empty. That will block the thread as you have noticed. This should not be necessary if I compare it with other FTDI drivers. You can test the new version (in debug directory). Please also test for larger transfers.
This answer was regarding another problem using Serial over USB and FTDI driver. Sorry if I confused you..
Thanks a lot for such a prompt answer.
I came back home and verified Open (after InitializeBT).
Open: If device is on, it takes a moment to connect (disconnect is a bit longer but still Ok).
Open: If device is OFF, it takes LONG to fail. This is my problem.
context: I wrote a HAM radio app where operator logs his/her connections. BT serial (or USB serial depending on radio model) is used to pool (or set) radio parameters in real time. Some functions are on separate screens. So the problem is when radio is not yet connected and is in the process of automatically connecting:
a) in order to overcome blocking nature of BT.Open I do it in background task
b) when I switch screen, the background task of BT.Open may end (BT connected) while app is on another screen throwing 3100 error
I use workaround to ignore this error from particular extension... but it IS Q&D and I feel it may have consequences (noticed some but did not trace then enough).
So it would be nice to either delay b) until BT.Open finishes or terminate this task or make a) truly asynchronous and handling case when user leaves screen.
best regards, Kuba SP5NZF
P.S.: Impact of the problem is limited so it is not that critical
