Not all the RobotC BT functionality is implemented. You’ll have to wait a bit to get messaging working.

Regarding why some functions have “void” return types requires a bit of understanding of the NXT iteration functions and of the functions. If you already know all this stuff, then skip to the end of this post.

NXT Iteration Functions:

If you read the Development Kit documentation, in particular the Fantom commands you’ll find a bunch of “iteration” functions. They all have a set of common functions.

1.       Start iterating through a list of items. Internally the handle is usually a 16-bit value with the upper byte containing an error code and the lower byte containing an internal index of some sort.

2.       Query functions to obtain information about the current item. The input parameter is the handle and the output parameter(s) are information about the  item that the handle references.

3.       An advance to next item function. You pass it the current handle and it returns an updated handle containing the next item in the list.

4.       A close function to release the handle.

You’ll find Fantom and NXT firmware uses this iteration scheme for:

·         Getting the list of NXT resources (USB or BT) that are visible to the PC. (Fantom)

·         Iterating through all the files on the NXT. (Fantom, NXT f/w)

·         Iterating through all the software modules on the NXT. (Fantom, NXT f/w)

·         RobotC has also exposed a new iteration “class” for gaining access to the BT contacts list sotred in the “communicatons” software module. This is the data that is also exposed in the ‘comm’ IOMAP as array variable “BtConnectTable”.

NXT Functions that Require Multiple “Timeslices”:

There are many examples within the NXT firmware where a function is requested and you must wait while the requested function is executed before you are able to obtain the results.

One good example is sending I2C messages to the NXT digital sensors

·         You start an I2C message request. It will take several milliseconds to execute as the transmission speed of the sensor I2C busses is about 1 byte per millisecond (standard firmware) or 5 bytes per millisecond (RobotC firmware talking to 3rd party sensors).

·         You should be polling the status (waiting, completed without errors, error found) before you can obtain the results, if any, returned by the sensor.

·         Once the status is no longer waiting, you can obtain the results

The NXT Bluetooth implementation operates very similar to the digital sensors

·         The heart of the BT low level implementation is in a separate Bluecore hardware module. It communicates to the main ARM CPU via a serial linkbut at a much higher bandwidth (400 kbps).

·         So invoking a BT function that requires communication with the Bluecore module will have the same type of implementation – send message over I2C bus, wait for Bluecore to process and send reply, now act on the reply.

NXT Bluecore Communications Links

The Bluecore chip has a I2C and serial link connection to the NXT. The I2C link is only used for downloading new firmware into the Bluecore flash; there is no implementation to support this in the current NXT firmware.

The serial link is the only communication link used between Bluecore hardware and NXT CPU. It has two modes of operation:

1.       “Command” mode is used to send configuration commands – set up link, open/close connections, … - to Bluecore.

2.       “Data” mode is used to transmit and receive data over the Bluetooth wireless link.

There are also a couple of I/O pins that the NXT CPU uses to control the Bluecore (e.g. a reset pin, a ‘mode’ pin that toggles serial link between “command” mode and “data” mode.

Bluecore Data Mode vs Command Mode

The serial link can only be in one mode or the other. When it is in command mode, then any data transmitted or received over Bluetooth is discarded. There may be small buffers in the Bluecore chip so that some data is retained but I’m uncertain of this.

NXT firmware does include message buffering. If the Bluecore is in command mode, then firmware will buffer outgoing messages generated until Bluecore is switched back to data mode.

Bottom line of this is that if you’re trying to setup multiple BT connections on a NXT then do this before trying to send data. Otherwise, when you try to set up second connection, you risk the possibility of dropping incoming data.

The NXT CPU and Bluecore have implemented a very low-level protocol on top of the serial link for sending packets of data.

·         The packet begins with a length field containing the number of bytes in the packet.

·         The actual data bytes follows

·         Command mode packets also include a checksum field

Bluecore Streams

BT will theoretically supports up to seven concurrent streams (i.e. wireless connections) on a single BT device. The Bluecore chip used on the NXT only supports three simultaneous streams.

However, the current implementation only allows communications for one stream at a time. Looking at the packet protocol described above, there is no “stream number” field in the packet. Instead, the NXT CPU tells the Bluecore which stream should have its data sent on the serial link; data from the other two streams is dropped – I’m pretty sure it is not buffered in the NXT.

This implementation does put some restrictions on the NXT BT capabilities:

·         The NXT CPU can only receive/transmit data from one stream at a time.

·         TO prevent loss of message, the NXT implementation is different between master and slave. Slaves do not autonomously send messages; instead they buffer them and only transmit in response to a poll for available messages from the master.

·         Slaves can only have only BT stream which must be continuously connected to the serial link.

·         When there are multiple BT connections on a master, then the master sequentially transmits and polls messages to each slave in a round robin fashion.

·         You cannot have both slave and master connections on a single NXT. This means if a NXT is a master connected to other NXTs via BT that you cannot have a BT connection between PC and the NXT because PC is the master – so debuggers won’t work over BT in that case.

NXT Functions that Require Multiple “Timeslices”:

Now I can finally post replies to some of your questions.

·         Some functions have void return values because they are simply interrogating data in the NXT and should not fail and do not require multiple timeslices to complete.

·         Instead of trying to use the RobotC connection setup functions you could achieve the same thing via the NXT GUI or via setting up a PC connection to the NXT using fantom or one of the third party tools.

·         RobotC does not (currently) expose an interface that allows you to send and transmit messages via BT. This capability is currently an internal DLL.

However, there are a variety of third party solutions that others have developed on the web. You might explore using one of the these. They should be compatible with RobotC firmware as long as they are compatible with the “Fantom” messaging protocol defined in the Development Kits.

·         You found a variety of “send message” functions in the RobotC interface. These are legacy functions from the RCX implementation and haven’t been ported to the NXT implementation at present.

·         The biggest problem you’ll find is that the BT messaging in RobotC is not yet reliable so it is currently disabled in the firmware. I need to find a couple of days to properly test and debug.

·         RobotC messages are a little more flexible, but still compatible with standard firmware. I believe standard firmware only supports messages that are either a number or a string. RobotC supports arbitrary user defined formats such as a ‘cast’ of the message data from a structure.

When BT messaging is re-enabled, I will post another message.

 

 

·