New MessageRead feature in the enhanced NBC/NXC firmware

[afanofosc]

In the enhanced NBC/NXC firmware version that I uploaded earlier today I have implemented a new feature in the MessageRead system call which underlies the ReceiveRemote* API functions in NXC (and ReceiveMessage along with SysMessageRead).

In the standard firmware, as has been explained on these forums before, if you have multiple slaves attached to a master NXT and you try to read, for example, MAILBOX1 then the firmware will attempt to retrieve a message from one of the slaves to put into MAILBOX1 if it happens to be empty when you execute the MessageRead system call function. The firmware starts with connection one the first time you call SysMessageRead if the mailbox is empty. The second time you call it tries connection 2 if the mailbox is still empty. The third time it tries connection 3 if the mailbox is still empty and it keeps on going around all the active connections until it eventually gets a response from a slave that puts a message into the mailbox you are trying to read from.

This gives the user no control over which connection gets used next regardless of which mailbox you may have your slaves configured to use. If you only have one active connection then there is no issue at all with this design but it definitely can cause problems when you have multiple active connections to other NXTs.

What I have done is made it possible to OR into the QueueID the connection number that you want to restrict the firmware to using if it finds an empty mailbox. You pass the connection number in as a value from 1 to 3 shifted left 6 bits. In other words, 0x40 = 1, 0x80 = 2, and 0xC0 = 3. If you want to read MAILBOX1 from connection 1 then you would pass MAILBOX1 | 0x40 into the API functions that read from a mailbox. With the enhanced firmware this will make it so that if the mailbox is empty it will only attempt to read from the remote device on the specified connection and not round-robin through all of the active connections.

I'd love to have some help testing this new feature and comparing the behavior with that of the standard firmware when you have multiple active connections and you use a different mailbox for each slave.

Just keep in mind that Bluetooth communication can be tricky - especially when you put functions that interact with the Bluetooth subsystem all throughout your program and call them in multiple tasks.

John Hansen

[HaWe]

that sounds really promising - although I admittedly do not understand anything about how to use this feature!
Could you please provide me/us by a source code example for master and slave procedures (endless tasks) how e.g.,

on the slave: produce random strings (updating about every 10-20 ms) and put them into outboxes

and on the master: read message strings continuously from mailboxes of 3 slaves one after the other
(about up to 50ms delay for each slave => about up to <= 100-200 ms for reading 3 strings from 3 slaves over all) ?

for COMM 1: OUTBOX=1, INBOX=2
for COMM 2: OUTBOX=4, INBOX=5
for COMM 3: OUTBOX=7, INBOX=8

I'd really love to test them, and I dare say, I already got a perfect testing platform :)

[ronmcrae]

Letting us limit the mailbox search to a single attached brick is great. It works well. I was able to eliminate a 0.3 second synchronization delay once I updated the FW and setup the 0x40 and 0x80 values to restrict the search for messages to one specific brick. This was one master with two slaves, but from what I've seen I'd now be inclined to consider a MOC with three BT'd slaves without having to worry too much about BT latency.

[afanofosc]

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

[mcsummation]

John, I want to thank you for the work you are putting in on this. You are quickly getting the Bluetooth stuff working the way it really should work.

[HaWe]

I'd really like to test this because the standard BT protocol is far too shaky, but unfortunately I don't see how to write code to use it in my programs...?

[HaWe]

did I understand something wrong or did I express myself misleading?

[afanofosc]

As explained in my original post, you simply add a value to the mailbox number.

In other words, 0x40 = 1, 0x80 = 2, and 0xC0 = 3. If you want to read MAILBOX1 from connection 1 then you would pass MAILBOX1 | 0x40 into the API functions that read from a mailbox.

The value you add depends on which connection you want to restrict the firmware to for the specific mailbox. You would only use this mechanism on the Master NXT when you call ReceiveRemote* or ReceiveMessage or SysMessageRead, i.e., the three families of API functions that let you read from a mailbox and which do not take a connection number as a parameter value.

Code: Select all

char x;
string strval;
byte queue = MAILBOX1; // pick a mailbox
queue += 0x40; // restrict the firmware to Bluetooth connection 1
//queue += 0x80; // restrict the firmware to Bluetooth connection 2
//queue += 0xC0; // restrict the firmware to Bluetooth connection 3
// alternatively, you could use queue = MAILBOX1 | 0x40; i.e., you could OR the mailbox number with the connection constant.
// the NXC API will have predefined connection constants Real Soon Now (RSN). i.e., something like #define MAILBOX_CONN_1 0x40, etc...
x = ReceiveRemoteString(queue, true, strval);

John Hansen

[HaWe]

hmmm, my English and my fw function knowledge is too poor, I will probably have to sleep a few weeks about that...
Or could you write a new API function which has this feature already automatically implemented/included
(and I still don't understand quite the difference or the (dis)advantage when using the old or the new feature - will it help me with my message dropping and running into multithreading interferences and the redundant-send/receive failures?)

[afanofosc]

Doc, you could just try the code I posted without all the extra documentation comments that I added. It seems pretty straight-forward to me. This new firmware feature will not protect you from badly designed code, which as far as I can tell is the root cause of the problems you are encountering.

John Hansen