Android Question DoEvents in serial communication

entolium said:

use "DoEvents", the event "serial_DataAvailable" don't raise

Click to expand...

you can not hold the mainthread. Using doevents is most probably the wrong solution.

Send the message, wait for the event get raised. Send the next message then.

Thank you DonManfred.

I Know, DoEvents is not a good idea, but I have not idea how can do it.

I can't wait always the same time, because the response could be sort or long. Waiting the same time for all response would do the app very slow.

if you need to send 10 packets.
Create a global list with all packets to send.
Add all Packets to the list.

Get the first item from list and send the packet.
Wait for the result event get raised.
In the event you now remove the first item.
Check if the list contains more items. If yes, get the first one and send it.
Wait for the result event get raised.
In the event you now remove the first item.
[...]

I think I have the same problem.
I can use a list of commands and a list to responses to compare, but I have not a timeout control (the communication can break).
Could be possible, but I think will be very complicated .

entolium said:

the communication can break

Click to expand...

Then the result event wont raise. You can use a timer to check if a answer arrives after x seconds...

Sorry, that´s all i can help. Never used serial-communications in b4a.

DonManfred said:

you can not hold the mainthread. Using doevents is most probably the wrong solution.

Click to expand...

That is the correct answer. DoEvents will not help.

Note that AsyncStreams_Terminated or Error events will be raised if the connection breaks.

Thank you for your help.

All my apps use serial communications, trust me its fun as it takes some getting used to since the VB6 days.

This is how I do it:

I create a routine that sends packets. Each packet is assigned its own event ID, or if the packet is always the same with a few changes, I just pull from global variables and rebuild/send packets.

I then start a timer of a defined value. I transmit the packet, and then I finish the subroutine.

The RX event will fire, or the timer will fire. RX event fires when there is an ACK or some other form of data, and from there I parse it. compare it against my eventID or some other type of variable so the program knows where I am at, persay.

If the RX event doesnt fire, the timer will. The timer fires, and either retries the send, or aborts the routine on a time-out condition. Failed to respond, etc..

Once the RX is complete, I call a subroutine that moves my variables to the next state, and starts a 2nd timer.

the 2nd timer fires, and calls my send routine with the new variable data, thus starting the process over again for the next sequence.

Every subroutine involved has checks and balances in it that make sure the serial connection is still present, or some other abort sequence hasnt fired. If any get met, then the whole operation gets aborted. (Other subroutines like buttons can fire while your timer is running or your waiting on an RX)