BluetoothStatus and BluetoothWrite return codes?

[kschaffer]

I've moved my Bricxcc project to a new computer and am having troubles debugging a Bluetooth connection that worked on my old machine.

I'm using BluetoothStatus, which is returning -32. According to the NXC manual, there are 3 return values:

NO_ERR 0
STAT_COMM_PENDING 32
STAT_MSG_EMPTY_MAILBOX 64


Is the -32 a 32 with a high bit flag set? If so, what does it mean? If not, what does -32 mean?

I am also getting -32 return value for BluetoothWrite. Is this the same return code space as BluetoothStatus' return value? If not, what does this mean for BluetoothWrite?


Note: I am using 0 as the argument, which, according to the docs, should be the PC, as it is supposedly "master" whenever connected to the device. BTW, I disconnect Bricxcc before trying to open the com port on the PC to read the data I'm trying to send from the brick. The ports are com3 and com4, and seem to open just fine, though I think it's com3 I should be using, but I've tried both. No data comes across (on the new PC.)



BTW, old machine was XP, new is Windows 7.

[afanofosc]

-32 == channel not ready

See line 494 here: http://bricxcc.svn.sourceforge.net/view ... iew=markup

This generally means you tried to write via bluetooth when the firmware had not yet completed the previous request to write via bluetooth. You need to wait until status returns NO_ERR (0) before you try a subsequent bluetooth write.

Code: Select all

NXT_STATUS cCmdBTCheckStatus(UBYTE Connection)
{
  //If specified connection is invalid, return error code to the user.
  if (Connection >= SIZE_OF_BT_CONNECT_TABLE)
  {
    return (ERR_INVALID_PORT);
  }

  //INPROGRESS means a request is currently pending completion by the comm module
  if (VarsCmd.CommStat == INPROGRESS)
  {
    return (STAT_COMM_PENDING);
  }
  //Translate BTBUSY to ERR_COMM_CHAN_NOT_READY
  //And check if specified connection is indeed configured
  else if (VarsCmd.CommStat == (SWORD)BTBUSY
       || (pMapComm->BtConnectTable[Connection].Name[0]) == '\0')
  {
    return (ERR_COMM_CHAN_NOT_READY);
  }
  else
  {
    return (UNPACK_STATUS(VarsCmd.CommStat));
  }
}


NXT_STATUS cCmdWrapCommBTWrite(UBYTE * ArgV[])
{
  SBYTE * pReturnVal =  (SBYTE*)(ArgV[0]);
  UBYTE Connection   = *(ArgV[1]);
  UBYTE * pBuf;
  UWORD BufLength;
  DV_INDEX DVIndex;

  //Resolve array arguments
  DVIndex = *(DV_INDEX *)(ArgV[2]);
  pBuf = cCmdDVPtr(DVIndex);

  BufLength = DV_ARRAY[DVIndex].Count;

  //If there's an old error code hanging around, clear it before proceeding.
  if (VarsCmd.CommStat < 0)
    VarsCmd.CommStat = SUCCESS;

  //!!! Only first 256 bytes could possibly make it through! Should return error on longer input?
  //!!! Not requesting a wait-for-response because only known use doesn't read responses.
  pMapComm->pFunc(SENDDATA, (UBYTE)BufLength, Connection, FALSE, pBuf, (UWORD*)&(VarsCmd.CommStat));

  //!!! Reasonable to wrap below code in cCmdCommBTCheckStatus?
  //INPROGRESS means our request was accepted by His Funkiness of pFunc
  if (VarsCmd.CommStat == (SWORD)INPROGRESS)
  {
    *pReturnVal = STAT_COMM_PENDING;

    //Set DirtyComm flag so stream is reset after program ends
    VarsCmd.DirtyComm = TRUE;
  }
  //Translate BTBUSY to ERR_COMM_CHAN_NOT_READY
  else if (VarsCmd.CommStat == (SWORD)BTBUSY)
  {
    *pReturnVal = ERR_COMM_CHAN_NOT_READY;
  }
  else
  {
    *pReturnVal = UNPACK_STATUS(VarsCmd.CommStat);
  }

  return (NO_ERR);
}

[kschaffer]

Thanks, I'll see what I can do with this. Is there flow control? If nothing's reading off the other end of the pipe, do things get backed up, and what's the error message if so?

[kschaffer]

Ok, as long as I follow this sequence, I'm OK:


1. Upload NXT program from Bricxcc.
2. Close communications on Bricxcc.
3. Start my C++ program on the PC which opens the serial port (com3 in this case).
4. Start the program on the brick.
5. Data is received.
6. End program on the brick first.
7. End C++ program on the PC
8. Go back to Bricxcc and re-connect to repeat.


If I start the brick program first, I get -32, always, even after opening the com port on the PC side. Maybe I can robustify this a bit by figuring out and calling some kind of BluetoothResetYourself()-style function, brick-side.

[kschaffer]

1. To **send** to the brick, I want to use the other COM port or the same one?

2. I note the data I send from the NXT seems to be received by the PC in this format:

unsigned byte len
unsigned byte ??? <-- BT address 0..3? Always 0, which would make sense as the PC is 0.
data

So I would use this format to send the other way back to the NXT? If so,

A. How do I bundle up a "direct command". My program would not need to listen in this case? I could drive the motors this way?
B. If not and my program needs to read, there appears to be no equivalent BluetoothRead brick-side. What would I use instead?