doc-helmut wrote:but what if multithreaded programs demand to use BT remote functions independently?
1 task reads local and remote sensors,
1 2nd task controls local and different remote motors depending on sensor events ("Remote_OnFwd until Remote_Touch is pressed" or "...until (RemoteLightSensorRaw>500)"
1 3rd task reacts to user interrupts and has to follow it's instructions like send BT messages to any other device for what purpose ever.
BT has just 1 sense: muliply the number of all I/O devises of the the local NXT by all numbers of all NXTs overall: 4 NXTs= 12 motors and 16 sensors to be controlled and read.
I will not restrict my programs on what they do locally with my I/O devices, and I won't restrict them what they do on remote NXTs.
BT must not restrict what tasks ever need to do - what tasks may do locally, they must be able to do on remote devices (slaves) as well. BT messaging must support this safely.
Why not add a 4th task that handles BT? It could share common resources globally for the other tasks to read and write. Any task could read or write to the resources (buffers) at any time (protected to be thread-safe), and the BT task would deal with the new values the next time it gets around to it.
I disagree with you; BT is used for much more than an IO expander.
You need to realize that the NXT is not a blob of magic that John can enhance by simply waving a wand. There are many restrictions which can't be over-come by thought, or even the smartest SW. If you are going to continue using the NXT, you need to accept that fact, and deal with it the best way possible (which John has been trying to tell you). There are work-arounds for many of your NXT "problems", you just need to implement them.
mcsummation wrote:Sorry, John, but my mind simply designs multi-threaded communication apps. I've been doing it for many years and It hurts when I tell the design part of my head - "single thread".
I'm going to continue to tinker with this the next time I need to do an NXT/NXT application. I think I've got a way to make it thread safe and reliable, but I'm not going to post it here...
Well, the NXT is much more limited in it's resources than many other systems. For someone who was/is a computer programmer, it probably takes some getting used to.
If you have found a solution, why not post it for all to see?
If I were to use BT in multiple tasks, I would go about it wrapping every BT related function in a common mutex.
Why not add a 4th task that handles BT? It could share common resources globally for the other tasks to read and write. Any task could read or write to the resources (buffers) at any time (protected to be thread-safe), and the BT task would deal with the new values the next time it gets around to it.
not possible, believe me - at least not for me.
And it's not the way my MT programs work - everything is multithreaded and alway will be.
But you may try your luck with my chess program. Want my code?
I disagree with you; BT is used for much more than an IO expander.
What I'm saying, is that if you ran into a problem you can't make a work-around for, redesign it to the point that it works. I have had to completely redesign programs because of structural problems that showed up later.
I tried it but it worked even worse.
several tasks, each has it's specific timing.
So: it has to be multhreading-safe.
Having the described direct commands, they also must me multhreading-safe, but the continuous BT traffic might be not that heavy, that might make easier.
Anyone who wants to try to come up with a scheme that lets 100 different threads in an NXT program muck about with Bluetooth is welcome to do so but you are in for a lot of heartache and grief which is entirely and completely needless.
Just like you might dedicate a thread in a program to managing the ultrasonic sensor on port 1 and another thread to managing the touch sensor on port two and another thread to managing the motor on output A the approach that makes the most sense and which is easiest to implement is to dedicate a thread to managing all mailbox-based communication between multiple bricks. Sure, you can have 5 different threads in your program competing for access to OUT_A or the sensor on port 1 but why would you do that? If a thread needs to know what the most recent ultrasonic sensor value was then it can just read the global variable where the thread that manages that device put the last value it read. The same goes for mailbox values. Define a structure that represents all the values you want to read from a remote NXT. Create one instance of that structure that is the last good read from the NXT on connection1, another instance for the NXT on connection2, and a third instance for the NXt on connection3. One thread reads from a mailbox for each connection and Unflattens the value it gets back into the structure (an atomic operation). Any other thread simply reads the fields from each of these three structures to get the values from the remote devices. If a thread needs to send a message to a remote device it calls a safecall function that simply adds a structure (or a string, maybe) to the end of an array (queue of outbound messages) which the one and only communication thread processes. If the outbound message queue is not empty it pops a message off the front of the queue and sends it to the specified device (maybe the first byte of the string is the connection number). It guards access to the message queue using a mutex which is also used in the safecall function that puts messages into the outbound queue. A single byte in the message is the command byte so you have 256 possible commands you can send to a remote device. One command is a poll sensor command. Maybe this tells a remote device to load a response mailbox with values from all 4 inputs and all 3 outputs rotation counters. Another command is a setout command with parameters like port, power, mode, runstate, regulation mode, tachometer limit, updateflags, etc.. (up to ~50 bytes worth of parameter values). Another command lets you draw on the remote LCD, perhaps.
Anyway, this sort of approach is simple, flexible, powerful, and completely and utterly reliable and safe. The remote devices don't write to a response mailbox unless specifically asked to via a command from the primary NXT. The remote devices have a dedicated message handling thread which checks for and processes any incoming messages.
I will be writing a reference implementation of this approach this weekend, with any luck. You are all welcome to write your own or ignore my advice completely and spend countless frustrating hours beating your head against a wall with a complicated multi-threaded bluetooth scheme.
afanofosc wrote:I will be writing a reference implementation of this approach this weekend, with any luck. You are all welcome to write your own or ignore my advice completely and spend countless frustrating hours beating your head against a wall with a complicated multi-threaded bluetooth scheme.
I am eagerly awaiting this reference. I have been (today) writing Master/Slave demo code to implement your suggestions. I am going to show that your method does indeed work in a high traffic situation (hopefully).
I am putting in several of the Bluetooth subroutines that have been discussed in the past few weeks to make the code clean looking with all the ugly stuff contained in a separate library. I hope you will critique the library and code so we can get a definitive set of routines and programming model so other folks won't have to go through the "head banging a wall", like some of us have.
Edit: John, how about starting a fresh thread with your document. That way, maybe we can have a clean discussion about it.
I've been doing it for many years and It hurts when I tell the design part of my head - "single thread". 
