Really Unexpected Task Behavior

[spiked33]

Thanks, I will.

I will also look a little later at RemoteWrite. I'm trying to come up with the equivalent of the LeJOS RConsole. Just writing to the serial bluetooth stream without the mailbox paradigm would be fine.

didn't get too far;
task main() {
byte consoleHandle;
int bl = 5;
byte Buff[5] = {'h', 'e', 'l', 'l', 'o'};
RemoteOpenWrite(CONN_BT0, "untiltled1", 1024, consoleHandle);
RemoteWrite(CONN_BT0, consoleHandle, bl, Buff);
}

produces;
# Error: Invalid label argument: __RRWrite_End2
File "C:\Users\mikep\AppData\Local\Temp\temp.nxc" ; line 6
# brcmp 1, __RRWrite_End2, __main_7qG2_bl_7qG2_000, __constVal58
#----------------------------------------------------------
1 errors during compilation

[afanofosc]

Sorry about that. I've fixed a few API functions that suffer from this defect.

However, I am nearly certain that you do not want to do what you are doing. Do you know what these functions are for?

Probably all you want is to write using BluetoothWrite.

John Hansen

[spiked33]

Thanks again John, you are correct. I am in the call anything and see what it does mode.

I have since tried the plain bluetooth write, and saw the characters on the PC, but then the NXT locks up hard. So I still have some experimenting to do.

[afanofosc]

My guess is that you are writing too frequently or something like that. The firmware does a ton of things asychronously via a bunch of different state machines in the various firmware modules. For example, calling OnFwd() doesn't actually start the motor(s) moving at all. It just sets some fields in the Output module IOMap structure. The same goes for configuring a sensor port via SetSensorType() or any other sensor configuration function. The same goes for BluetoothWrite. All these functions do is set fields in IOMap structures for different modules such as the Comm module (BluetoothWrite) or the Input module (SetSensorType). It could be up to 1ms later that the firmware actually does something with the values that you put into a module's IOMap structure. In the case of changing a sensor type or mode you are also supposed to set the InvalidData flag in the Input module's IOMap structure to TRUE. The Input module's Ctrl function gets called by the firmware once every millisecond (or so) and if you have changed a sensor's type or mode and set InvalidData to TRUE then the Input module's Ctrl function executes a state machine which advances (usually) one state per call to the Ctrl function. It takes some sensors as long as 300 calls to the Ctrl routine (the sound sensor) or even 400 calls to the Ctrl routine (the color sensor) before the firmware will reset the InvalidData flag back to False.

This is something like how writing to Bluetooth works as well in the Comm module. You call BluetoothWrite and it puts your data into the Comm module's internal structure and then every time the firmware stops your code that is executing in the VM in the Command module and gives all of the other module Ctrl routines a chance to execute the Comm module's Ctrl routine will execute its internal state machine to process the Bluetooth fields in its IOMap and, if necessary, transmit whatever data you asked it to do. The process of sending it out will occur gradually over the course of multiple calls to the Comm module's Ctrl function. While it is in the middle of sending out the last requested transmission it is crucial that you not muck about with the fields in the Comm module IOMap structure or you could wind up crashing the firmware. You avoid stomping on the current transmission by checking the BluetoothStatus.

Something like this (untested):

Code: Select all

// make sure we aren't already sending
  until (BluetoothStatus(CONN_BT0) == NO_ERR) Yield();
  char result = BluetoothWrite(CONN_BT0, buffer);
  while (result == STAT_COMM_PENDING) {
    Yield();
    result = BluetoothStatus(CONN_BT0);
  }

You would probably also want to check for other error codes that can be returned from BluetoothStatus such as

Code: Select all

#define STAT_COMM_PENDING 32 //0x20 Pending setup operation in progress

#define ERR_INVALID_PORT   -16 // Bad input or output port specified
#define ERR_COMM_CHAN_NOT_READY -32 //0xE0 Specified channel/connection not configured or busy
#define ERR_COMM_CHAN_INVALID   -33 //0xDF Specified channel/connection is not valid
#define ERR_COMM_BUFFER_FULL    -34 //0xDE No room in comm buffer
#define ERR_COMM_BUS_ERR        -35 //0xDD Something went wrong on the communications bus

#define NO_ERR 0

John Hansen

[spiked33]

In my first attempt, I was doing 1 write then exiting (which in itself could be a problem I suppose).

My latest attempts are not locking machine up, but all I get is an occasional buffer of 0s.

I hate to bug you, when I know I have more digging to do myself (i've read the legos bluetooth guides several times cover to cover) but I'm trying to wrap my head around this connection protocol. I can understand in an nxt to nxt the slave/master why fors, but I am not sure I understand it from a PC perspective. On my PC I open a serial port, com6. I never open anything on the nxt, and even the menus suggest opening a contact 1-3 (assuming it takes the master role 0). So do I bluetooth send CONN_BT1 or CONN_BT0? So far, I have never seen anything under any circumstance where 1 sent anything, including the use of mailboxes, only 0.

I got somewhat distracted today;



Some of it is mockup, the editor is not; http://www.codeproject.com/Articles/424 ... ext-Editor

Mike

[mcsummation]

I hate to bug you, when I know I have more digging to do myself (i've read the legos bluetooth guides several times cover to cover) but I'm trying to wrap my head around this connection protocol. I can understand in an nxt to nxt the slave/master why fors, but I am not sure I understand it from a PC perspective. On my PC I open a serial port, com6. I never open anything on the nxt, and even the menus suggest opening a contact 1-3 (assuming it takes the master role 0). So do I bluetooth send CONN_BT1 or CONN_BT0? So far, I have never seen anything under any circumstance where 1 sent anything, including the use of mailboxes, only 0.

Oh, a BT question I feel qualified to answer! The Master initiates the connection, the slave doesn't have to do anything. (This is true whether it's NXT/NXT or PC/NXT.) To the Slave, the Master is always connection 0. So, on the PC you open the connection over serial port whatever (6 in your case). The NXT's low level code will set up the connection. You then need to start the program in the NXT, which you can do from the PC. I'm using the C++ communication library from http://www.norgesgade14.dk/bluetoothlibrary.php, so the following code is what I use:

Code: Select all

#include <cstdlib>
#include <iostream>
#include <string>
#include <conio.h>
#include "nxt.h"
#include "BluetoothIO.h"
using namespace std;

//set up the NXT
Connection *connection = new Bluetooth();
Brick *nxt = new Brick(connection);
BluetoothIO *bluetoothIO = new BluetoothIO(connection);
int main()
{
  char keypressed;
 
  try{
    cout << "Try to connect to the NXT" << endl;
    connection->connect(12);
    cout << "Connected" << endl;
    cout << "Start the 'PC Drive' program" << endl;
    nxt->start_program("PC Drive.rxe", false);
// My code, lots of it using BT
    connection->disconnect();
  }
  catch (Nxt_exception& e){
    //some error occurred - print it out
    cout << e.what() << endl;
    cout << "error code: " << e.error_code() << endl;
    cout << "error type: " << e.error_type() << endl;
    cout << e.who() << endl;
    connection->disconnect();
  }
  return 0;
}

[afanofosc]

If you create the connection using your PC then it is the master which means it is connection 0 on your NXT which is operating as a slave in this case. It should show your PC as the device connected in slot 0 if you have correctly established the connection between your PC and your NXT.

The NXT will always stick 2 bytes at the start of any bluetooth transmission that indicates the length of the subsequent message.

My guess is you are doing something wrong on the PC side. A Bluetooth connection is SPP mode creates 2 virtual serial ports. Maybe you can use the other one?

John Hansen

[spiked33]

Ok, now I'm even a little bit more confused. Creates 2 connections, so I should use com6 to send and com7 to receive?

The C++ communication library I believe deals with the NXT protocol. I don't want protocol, I want a raw serial stream (except the length bytes, I can live with those).
I will take a look at it again to see if it has any raw stuff in it, but otherwise it's the same mailbox message stuff, which is getting dropped (and I already have working).

latest IDE, not a mockup - it is function, compiles and downloads using nbc command line. And the black console is a serial live connection to the NXT (waiting for me to get back to that task).

[afanofosc]

What you really should do is use the Fantom drivers.

I do not understand what you mean by:

but otherwise it's the same mailbox message stuff, which is getting dropped (and I already have working).

If you use BluetoothWrite there is no protocol other than the length bytes. No mailbox stuff. No direct or system command format. Just bytes. If you are using a library written by someone else that expects to deal with direct and system commands then you'll need to use something else.

I'm not a big fan of helping people write an IDE that they hope people will choose to use instead of the BricxCC IDE. The fewer people using my tools the less reason I have to spend my leisure hours with LEGO MINDSTORMS.

John Hansen

[spiked33]

John, I'm pretty sure my PC side code is correct. It works fine when I use a mailbox send type API on the lego. using bluetoothwrite from the lego, I never see any data (same PC code). But as we all know, never say never and I will keep looking at my code to see if I may have a problem.

I was going to ask you about the IDE before I distributed it. I am 30 years familiar with MS Editor, and I had a hard time adjusting, I even considered getting the Bricxx source and tweaking it just for me, but you can not even buy delphi anymore and it never became public domain, so while you are graciously open source, in practical it is not. Now I know how you feel, consider it done, it will not be distributed, its just for me, code away