Bug? Serial communication with AsyncStreamsText module

GiovanniPolese

Well-Known Member
Licensed User
Longtime User
Hi to all.
Premise 1: probably this post is of no interest for users that don't use Serial Bluetooth communication and it is devoted to users that know what I am talking about (I cannot write much more on the subject; my purpose is to alert other people and, possibly, get an explanation of what happens; by the way I anticipate that I "empirically" resolved the issue, but I don't know why..).
Premise 2: my project is not complicated but it is bound to particular hardware, so it is useless to post it
Premise 3: what I expose here are simply "facts" that I met. I cannot exclude a mistake on my approach to the problem.

The application sends commands to a device and waits an answer from it. Then does some elaboration and sends results over Internet to a remote server. Due to this structure, it is "doubly" asynchronous.
I use OkHttp2 library for the Internet communication, while I use AsyncStreamsText.bas module and Serial lib for serial communication over Bluetooth. Versions are the latest. I took AsyncStreamsText.bas module from posts on the site, and did no change at all. Moreover, the entire App is developed starting from Serial communication example, so there is a Main module and the AsyncStreamsText module.
I have put a Log("SubName") in each Sub of the Main, so I know when and how the Sub is called.
Inside the AsyncStreamsText.bas module, there is a CallSubDelayed2 raising an event in the main module, i.e. calling a Sub Serial_NewText in the Main.

Fact 1: In the Log, I see twice the Log("SubName") message. I cannot understand whether the main module Sub is actually called twice, or the Log(Message) only is displayed twice. I am speaking of all Subs in the main, not only of the Serial_NewText function called by AsyncStreamsText module. (Why I focus attention on this latter, will be clarified in the following).
Fact 2: I have two global variables, one for storing the result of the Instrument answer and one for copying the previous one. I get a value from the text arrived on Serial_NewText(Text as string), like, for example: double Var1=Value extracted from Text. In another sub of the program, obviously not called in the meanwhile, I copy Var1 value in another variable: Var2=Var1. Both Var1 and Var2 are Global double variables. The fact is that, when Var1 is modified according to the new text arrived, also Var2 is modified. I understand that I am telling a nonsense, but must be clear (obviously) that no Var2=Var1 is called between Var1 assignment and Var2 inspection (no question about, and the proof is the fact 3 following).
Fact 3: all above problems disappear substituting the CallSubDelayed2 call in AsyncStreamsText.bas module with simple CallSub2. Sincerely I am suspicious about this empirical solution that I found.
Final notice: I have already had problems using CallSubDelayed calls and decided not to use them in general. I my opinion their use is not as simple as explained in the basics. Of course what I described here could be a basic mistake on my side, but I would like to know why, in this case, things work well with the empirical modification... if I did a mistake, the program should not work in any case ..
 

GiovanniPolese

Well-Known Member
Licensed User
Longtime User
Hi. The problem is that even a simple project needs a device to connect on Bluetooth. I made a simple program, but to test it, you should connect to a device similar to mine. Actually there is nothing strange in my devices. They just receive Ascii strings as commands and answer with Ascii strings with normal terminators (Cr/Lf). The problem is that commands take very different time to be executed, so the answers arrive with different delays (but serially, anyway, no superimposition).
As a matter of fact, the attached devices are robot measuring stations, and some commands are for movements, not only for measuring. First type of commands take several seconds to be executed and the NewText sub is called with notable delay, while this is not true for measuring commands.
I post here the simplified version. Actually, in such a simple case, there are no problems and no difference using Delayed or not delayed calls.
The only thing that you can verify is that the Log messages are displayed twice. This is very curious and I wonder what I am missing.. I post a screen shot here, showing double log messages.
Instead, about the mysterious behavior on the variables, I think impossible to reproduce it on a test program. Sincerely I never seen such thing and still I am wondering where a mistake may be. Following step by step with debugger, there is no assignment to the Var2 that changes, when Var1 is assigned a new value. It is just like Var1 and Var2 variables were in an C "Union" structure. Or a very particular memory corruption, despite B4A is not C.

By the way, I am pleased to inform you that B4A was an excellent solution for my problem, and we are successfully carrying out an important bridge monitoring in Lisbon.
There is no question about the product validity, at least for Android, as I am using.
Best regards
Giovanni
 

Attachments

  • LogImage.png
    LogImage.png
    90 KB · Views: 276
  • Serial_Test.zip
    58.1 KB · Views: 251

GiovanniPolese

Well-Known Member
Licensed User
Longtime User
Hi. This post is just not to leave wrong information here, or to open other questions... Actually the double log message doesn't seem to depend by the use of CallSubDelayed in AsyncStreams. As a matter of fact, I put the delayed call again, and Log messages now correctly appear. Also, it seems not to depend on my device (Samsung tablet). In fact I only use that device. In the test project I previously posted, it was happening, as documented by the screen shot that I attached. The difference could be that to day I am using Usb cable debugging and not B4ABridge. Also the other mysterious variable mismatch doesn't happen. I don't know whether the two facts are related. Before, I "solved" the issue changing CallSubDelayed with CallSub, but perhaps it was only a "chance" that things worked after that empirical (and probably nonsense) modification. Unluckily I only use B4A for asynchronous programming on serial ports and internet, so I cannot say to have seen this behavior in other context. Instead, I can guarantee that double Log messaging is very frequent in my cases. Thanks for attention.
 
Top