no, it didn't help, sending and receiving is still always shaky and it blocks.
Still no way for sending and receiving BT messages safely yet.
I also tried it this following way using completely single centralized BT tasks - no chance, no BT messaging at all, total blocking;
it neither works with
Code: Select all
do {Wait(1);} while (BluetoothStatus(ID) == STAT_COMM_PENDING);
nor using
in the master task.
Code: Select all
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
task BTMasterTask() // NOS = Number of Slaves
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
{
string slvmsg;
string pollmsg="¦¦";
int ack, ch;
char ID;
pollmsg[0]=0xff; pollmsg[1]=0xff;
while(true) {
if (_NOS_>=1) {
ID=1;
SendRemoteString(ID,OUTBOX_1,pollmsg);
do {Wait(1);} while (BluetoothStatus(ID) == STAT_COMM_PENDING);
//Wait(10);
ReceiveRemoteString(INBOX_11, true, slvmsg);
ParseBTResponseMsg(ID-1, slvmsg) ;
Wait(10);
}
if (_NOS_>=2) {
ID=2;
SendRemoteString(ID,OUTBOX_2,pollmsg);
do {Wait(1);} while (BluetoothStatus(ID) == STAT_COMM_PENDING);
//Wait(10);
ReceiveRemoteString(INBOX_21, true, slvmsg);
ParseBTResponseMsg(ID-1, slvmsg) ;
Wait(10);
}
if (_NOS_>=3) {
ID=3;
SendRemoteString(ID,OUTBOX_3,pollmsg);
do {Wait(1);} while (BluetoothStatus(ID) == STAT_COMM_PENDING);
//Wait(10);
ReceiveRemoteString(INBOX_31, true, slvmsg);
ParseBTResponseMsg(ID-1, slvmsg) ;
Wait(10);
}
ack=0;
if (_OUT_ != "") {
ch=checksum(_OUT_);
while(ack!=ch) {
SendRemoteString(_ID_, _OUTBOX_, _OUT_);
do {Wait(1);} while (BluetoothStatus(_ID_) == STAT_COMM_PENDING);
//Wait(10);
ReceiveRemoteNumber(_INBOX_, true, ack);
Wait(10);
}
_OUT_="";
}
Wait(5);
}
}
Code: Select all
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
task BTSlaveTask() { // slave
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
string in;
int ack, len;
string sp, sn, svv;
string fmtstr, buf, out;
int i, dec;
while(true) {
in= "";
if (ReceiveRemoteString(INBOX, true, in) != STAT_MSG_EMPTY_MAILBOX) {
if((in[0]!=0xff)&&(in[1]!=0xff)) { // ack for ExecCmd
ack=checksum(in);
SendResponseNumber(OUTBOX_2, ack); // error check
Wait(1);
__cmd=in;
ExecCmd();
}
else
{
out=""; // return value string
for(i=0; i<11; i++) { // Sensorports: 0...3 plus virtual ports
GetSensorValues(i);
Wait(1);
dec=SensorValueDecimals[i];
sn=NumToStr(dec); // value decimals
fmtstr=StrCat("%",NumToStr(dec),"d");
svv=FormatNum(fmtstr,SensorCurrArr);
out = StrCat(out, sn, svv);
} // for port i=...
if (StrLen(out)>58) strncpy(out,out,58); // 58 = max msg length
SendResponseString(OUTBOX_1, out);
Wait(1);
#ifdef debug
//TextOut(0, 0, out);
#endif
}
} // != STAT_MSG_EMPTY_MAILBOX
ClearResponseMailbox(OUTBOX_1);
Wait(10);
} // while(true)
}
afanofosc wrote:I'm thinking about adding a bit to disable the bluetooth poll operation entirely. I.e., bits 0-4 for the mailbox number, bit 5 for disable bt, and bits 6 and 7 for the connection number. Of course, it has always been possible to call RemoteMessageRead to directly control which connection to read from, followed afterward by an attempt to read from a mailbox but you could wind up triggering a potentially unwanted bluetooth request the way things work in the firmware. I think it might be useful to be able to try to read from a mailbox and be certain that it's not going to send out a bluetooth message unless you specifically ask it to. John Hansen
doc-helmut wrote:don't there really no good examples about real good and safe BT connections and fast and reliable value/string polling and sending from/to 3 slaves exist? - synchronized, without dropping messages, without clogging the mailboxes, without data loss?
afanofosc wrote:I am working on an example in my spare time. I hope to have it ready by the end of the week.
Patience, Iago, patience. John Hansen
doc-helmut wrote:Strangely, when sending 4 arrays[≈ 40] shortly one after the other to any slave, each slave seems to receive every "block-of-four" 3-4 times multiple, completely, redundantly, one block after the other, although the 4 arrays have been sent actually only once and then never, and this seems to muddle up the BT communication.
A fail-safe and simple BT comm protocol still urgently needed and very much appreciated!