Mindboards

a hardware restriction in the NXT Bluetooth implementation

is there the same restriction by Lejos or NxtOSEK?

On the other hand, the end-user shouldn't have to care about these details anyway.
If the code says "wait(20)" and BT is still busy it should wait 10 ms or anything more by itself until it's ready and then do the job.

Also, 20ms have been just a rough idea, 30 would be fine as well, but I also had wait(50) instead and it didn't work either reliably.

So not the 20, 30, or 50 ms delay are the big problem but the lack of quick and safe and convenient direct remote commands for the enduser, without mailboxes and bit-shifting and above all not having to worry about Bluetooth status idle or active or pending or no error or if/until mailbox empty or not.

doc-helmut wrote:

a hardware restriction in the NXT Bluetooth implementation

is there the same restriction by Lejos or NxtOSEK?

It is my understanding that the restriction is in the hardware and would apply to any "Operating System" running in the brick.

ok then,
I surely could live with threadsafe+convenient direct remote commands with 30ms pause in between.

If you need almost local speed, then I suggest you use RS485. It can be way faster than BT. Based on the baud rate of 921600, it should take about 0.6ms to send 64 bytes! In addition to the incredible speed, RS485 uses 128 byte buffers, instead of 64 for bluetooth.

if you got RS485 remote commands for 1 master and 3 slaves like I'd like to!
Some of my NXTs are quite distant from each other, but I got 2 long cables meanwhile (1m each)

Of course all remote commands have to be 100% multithreading-safe!
And I also have to send e.g., arrays[129] of char

I don't use RS485 "direct commands". I always program both NXT's to pull their weight, instead of one doing all the thinking (if a slave needs to run a motor until the light sensor >=30, I don't make the master monitor the light sensor for the value to turn off the motor).

If you want to be able to access sensors and motors over the "network", then you need to program it yourself. It really shouldn't be all that hard! You just need to use a master-slave setup (like the library I gave you before), and then use the arrays however you need for your specific robot.

It really shouldn't be all that hard!

it is too hard for me, but if it's easy for you: I'd appreciate it if you did it!

Direct commands is what I need, I don't want to program a multiplexer network: it's the same problem like I have with BT.

But I need a Multiplexer network, e.g., for my chess program and my map-and-explore-Service robot!
Either based on BT or based on RS485.

And all has to be safe for multithreading!

Well, it does sound like something that would be useful for many applications. However, I am very busy with programming other things for the time being. I'll add it to my long todo list.

...quite to the top, I hope... ;)

Hello there,

I was nearly two years off here - and it is still the doc-helmut / ford prefect working community? Well...

Bye marvin