Mindboards

this is a topic from our German Mindstorms forum.
the program gives error -32 or -2 with the EFW (1.31) , but no error with the SFW (disabled in the settings):

devnull wrote:Ok, hier kommt es:

Zuerst der Master:

Code: Select all

#ifndef _HS_LIB_NXC
#define _HS_LIB_NXC
//********************************************************
// High speed communication library for NXC
// Author: Daniele Benedettelli, 11 Jan 2008
// Contributors: John Hansen, John Barnes
//********************************************************

// Connecting two NXTs using a 6-wire cable between their ports 4,
// you can send strings and numbers at high speed

// initialize the port 4
void SetHSPort()
{
   // no argument, since the only high speed port is the number 4
   SetSensorType(IN_4, SENSOR_TYPE_HIGHSPEED);
   SetHSState(HS_INITIALISE);
   SetHSFlags(HS_UPDATE);
}

// send a string
void SendHSString(const string msg)
{
   byte mlen = ArrayLen(msg);
   SetHSOutputBuffer(0, mlen, msg);
   SetHSOutputBufferOutPtr(0);
   SetHSOutputBufferInPtr(mlen);
   SetHSState(HS_SEND_DATA);
   SetHSFlags(HS_UPDATE); //send it
}

// send an integer
void SendHSNumber(const int value)
{
   string msg = NumToStr(value);
   SendHSString(msg);
}

// receive a string
bool ReceiveHSString(string &s)
{
   byte inPtr = 0;
   int timeout = 0;
   byte event = 0;
   string buffer;
   SetHSInputBufferInPtr(0);
   SetHSInputBufferOutPtr(0);
   while(event == 0)
   {
      inPtr = HSInputBufferInPtr();
      timeout++;
      if (inPtr!=0) event = 1;
      if (timeout>MS_500) event = 2;
   }
   if (event == 1)
   {
      GetHSInputBuffer(0, inPtr, buffer);
      s = buffer;
      return true;
   }
   else
   {
      return false;
   }
}

// receiver an integer
bool ReceiveHSNumber(int &n)
{
   string buffer;
   if (ReceiveHSString(buffer))
   {
      n = StrToNum(buffer);
      return true;
   }
   else
      return false;
}

#endif

task main()
{
  SetHSPort();
  int val = 0;
  while (true)
  {
    SendHSNumber(val);
    val++;

  }
}

und jetzt noch der task main für den Slave (der Rest ist identisch):

Code: Select all

task main()
{
  SetHSPort();
  int val;
  bool check;
  while (true)
  {
    check = ReceiveHSNumber(val);
    NumOut(0,0,val,true);
  }
}

Das Problem steckt (soweit ich es lokalisieren konnte) in der Funktion ReceiveHSString, und zwar im Befehl inPtr = HSInputBufferInPtr();
Wenn ich diesen Befehl auskommentiere, dann kommt kein Fehler.
Mit der Lego-Firmware und ausgeschalteter Enhanced-FW-Compileroption funktioniert alles wie gewünscht, ich vermute mal dass der Compiler da Mist baut.

Just something I thought of looking at the code. If you flatten and unflatten the variables/strings, it would use less bytes than NumToStr/StrToNum (the string would only be the size of the variable, not based on the decimal places).

thx, but actually the issue is about the fw problem.

Should I fix a problem reported by a user who says

ich vermute mal dass der Compiler da Mist baut.

which Google says means

I guess that is building the compiler as manure.

I do not understand this:

the program gives error -32 or -2 with the EFW (1.31) , but no error with the SFW (disabled in the settings):

I don't know what "disabled in the settings" means. If I were to guess I would guess that it means that he does not have the enhanced firmware option checked but it could mean anything. I don't know what is meant by "gives error". Does that mean it aborts with a File Error message and a number (-2 or -32) or does it mean that a function returns a non zero error code of -2 or -32.

Perhaps your friend could provide you with the NBC code for both versions of this program.

John Hansen

ich vermute mal dass der Compiler da Mist baut.

This is better translated as "I suspect the compiler is producing nonsense." While "Mist" is directly translatable to "Manure", in this context it's more like "gibberish", "nonsense" or "rubbish". It's a fairly general term in German and not really considered rude.

- Xander

correct, Xander. The way English speaking people are struggeling with German expressions is the same as I as a German always am struggeling with your English terms.*)

*) edit: using Google translation

edit2: enabled/disabled in the settings for compiler options means:
enhanced firmware option checked: errors -2 or -32
disabled = not checked = sfw: no errors

edit3: he's not my friend, he is just any a user.

Ok, I'm the original poster of the problem in the german forum. I'll try to explain my problem in some more detail.
I tried to use the RS485 behind port 4 and had the current enhanced firmware on two bricks. On the master runs the first program that doc-helmut posted. The slave has almost the same, just the task main is replaced by the code in the second code-tag.
As far as I can pinpoint it, the problem is in the function "ReceiveHSString", the command "inPtr = HSInputBufferInPtr();". If I turn this into a comment, then no error occurs (the program doesn't work without this, of course, but no error). Otherwise I get a file error -32. I also tried to insert a Wait(2000) command in front of this line, but all I got was a file error -2. The Wait was never executed, the program terminates immediately. Then I replaced the Firmware with the original LEGO firmware, but I still got a file error (without a number). Then I remembered to turn off the "enhanced FW" option in the compiler, and was rewarded with a flawlessly working program. That's why I suspect that the problem lies within the compiler.

How can I generate NBC code from the NXC code? I didn't find an option for that in the BricxCC. If you could explain that, I'll provide you whatever you need.

PS: "mist bauen" is a term that just means "producing something that doesn't work, doing something wrong, making a mistake". Never trust an automatic translator to produce really good translations of terms like these.

The -32 is ERR_COMM_CHAN_NOT_READY which I am almost certain cannot be reported in a File Error program abort message. It can be the response code of a function that tries to write to a COMM module buffer while it is busy processing the last write request. That might happen on the master that is sending a message on the HS port. Reading the value of the HS input buffer in pointer via IOMapRead cannot cause a -32 error.

However, a -2 is ERR_INSTR (0xFE Illegal bytecode instruction). This can only happen if you try to run a program that is compiled for the enhanced firmware on an NXT that is running the standard firmware OR if you are compiling code with a version of the NBC/NXC compiler which doesn't know anything about the 1.28+ firmwares and try running that program on the enhanced 1.28+ firmware. If you have the enhanced firmware on your brick but compile the code for the standard firmware you cannot get a -2 error. Your best bet is to get a new compiler and BricxCC version from the test_releases folder and check 2.0 (aka 1.28+) compatible, enhanced firmware, and automatic firmware version options on the Compiler|NBC/NXC tab. The last of these three options will make sure that if you have a 1.0x firmware on your brick that it will automatically switch from the default 2.0 compatible option to target the 1.0x firmwares and if you have the standard firmware on your brick it will automatically switch from the default enhanced firmware option to target the standard firmware.

John Hansen

Ok, I had the 1.28 FW, and my BricxCC version is 3.3.7.19
Can this explain the problem?
But it was definitely the slave in both cases (-32 and -2), and the error disappeared when I commented this HSInputBufferInPtr() command.
Oh, something I forgot to mention: whenever I started one of these programs, Bluetooth was turned on! Maybe this will help to pinpoint the problem.

If my compiler version is indeed incompatible, then maybe the Wait command was compiled into some illegal code. So this sounds probable. But the -32 was definitely a file error! Both of them, actually! At least this is what the error message said. And the slave should not have tried to send something, as you can see from the code. Or did I mess something up there?

I'm not sure if you
- installed the latest bricxcc release (3.3.8.8)
- installed the latest test_release (-> 3.3.8.9)
- and downloaded the appropriate efw version (included in the test_release) to your NXT...?

If not I would strongly recommend to do it.