Bluetooth "extras"

[HaWe]

You are starting the slaves by the master, I can't do it that way.
But the BT connection itself is set up correctly, I can see that clearly.
Also with my old BT initialization I did it that way, and it was working fine.

So the BT inititialization can't be the reason why it is not working.
The way I am using the BT send/receive/remote/response functions (both the old and your new ones) is logical and should work how they have been implemented.

I guess the BT implementation by the fw itself is simply faulty and highly susceptible to interference.

What we need would be a completely different BT connection architecture. For a hobby programmer like me the current system is far too complicated, prone to failure and, additionally, also far too slow.

I think I sacrifice my multiple NXT chess project and abandon all the other projects depending on BT - BT as it is available by the current fw is endlessly frustrating and simply is a big crap.

[mcsummation]

There are a number of "I can't do it that way" comments scattered through all the threads where we have tried to help you.

It is my opinion that BT is not your problem. It's my opinion that you do not understand how to write multi-threaded code and many, if not most, of your problems are related to that.

[HaWe]

well, you also said that BT actually should be multi-threaded-safe, by your new functions this already should have been achieved, and you also wrote that to your opinion I have been using the JHS... BT functions correctly:

I have spent some time looking at your code. It appears that the BT communication should be working properly.

also to my opinion I used all functions and procedures logically and correctly.
BT between master and slaves was set up correctly - definitely.

[1]
In one endless thread, I am requesting values by first sending a BOOL and wait to get right away a string back, then I have a waiting period before I poll the 2nd slave.
then I send a BOOL to the next slave and also wait to get a string back right away, then again I have a waiting period before I poll the next slave.
[2]
In another thread (randomly / triggered by user interface) I send a string to a dedicated slave and wait to get a acknowledge number back, and I wait for this until it's ok.

Because all BT commands are (or should be) meanwhile threadsafe (safecall / protected by mutexes) no other thread should be able to cause interferences.

I don't see what should be wrong doing it this way, and if I understood you correctly, you also don't see anything wrong.

My multithreading code works absolutely fine when I stop the BT send/receive tasks.
I the moment I start something like
"wait until BTconn is not busy" or
"wait until Bool value sent" or
"repeat until ack==0x99"
everything blocks.
So the BT handshake between master and slaves (BT request => BT receive string / BT send string => BT receive acknowlege) must be faulty, not my MT code.

[HaWe]

maybe the send/receive request by bool works faulty.
I'll try it with send/receive by a number (0xff) asap.

[mcsummation]

I believe my BT routines are thread safe. However, just because they are thread safe does not mean your code is thread safe.

There is no fundamental difference between the Bool and Number routines, only how the data is interpreted.

[HaWe]

my code is "thread safe": I already explained what I am doing just above, and I also explained that those blockings or hang-ups only happen when BT waits for certain events.
If I outcomment the BT commands then e.g., the remote claw does not open or close, or the remote hand does not go up or down, but the rest of the movements and all the calculations are working fine.
So it's logically the BT "conversation" that does not work and blocks the whole program (waits for incoming or outgoing messages until eternity, and does not do anything else so long).

[HaWe]

update:

I switched everything back and recovered my old version BEFORE John's changes to the mailbox system and back to the standard BT send/receive functions, and I re-installed my old BT mailbox system with 3 different mailbox numbers for each slave = overall 9 mailboxes (instead of 4 identical mailboxes for all slaves altogether), without waiting for noBTError and without waiting for mailbox!= empty, and SIC:

no blocking any more,
every slave can be addressed correctly,
the remote motors work fine again,
I can receive all slave's values by the master again,
I can send my large array in pieces from my master to the slaves again
the slaves again build the whole array correctly out of the received pieces,
I can start the remote chess move generators on every slave by the master.

BUT:
I often I have again BT interferences
often messages are dropped (or corrupted)
acknowlege numbers which should signalize that a message was received correctly do not reach the receiver quickly enough
although the source code requires a message to be sent only once, they sometimes are sent 2, 3, or 4 times redundantly
redundant and unnecessary messages muddle up and clog the BT message queues

as soon as I wait again for noBTError and for mailbox!= empty like

Code: Select all

SendRemoteString(ID, OUTBOX, cmd);
    do {Wait(1);} while (ReceiveRemoteNumber(INBOX, true, ack)!= NO_ERR);

the program blocks again.

In 1 word:
again the old crap.