Bricxcc and firmware test versions

[afanofosc]

It's easy enough to go back to an earlier firmware version and BricxCC/NBC version and see if unmodified NXC code works differently with the older firmware or compiler vs how it works with the 1.31 firmware and 3.3.8.9 BricxCC build. If you see a difference then please post some sample code that I can use to reproduce the problem. I am almost certain that I haven't changed anything in UnflattenVar. About as close to 100% as I can be. Pretty sure I didn't change FlattenVar or Flatten either.

Is this related to using FlattenVar to write a structure to a file?

John Hansen

[mattallen37]

Yes it is in a way, related to "using FlattenVar to write a structure to a file". Here though, more specifically reading a string from a file, and converting it into a number. I realize now, that the issue is in how I wrote the file, however, it is now different than before.

[afanofosc]

Yesterday, I uploaded a new test release zip to the test_releases folder on the BricxCC page. The recently introduced SendRemoteString bug should be fixed. In this version I have also fixed some problems with the hi-speed (RS485) port system calls in the enhanced firmware and NBC/NXC API functions. I renamed a couple of functions to make their intent clearer. RS485Init is now called RS485Enable. RS485Exit is now called RS485Disable. I added a function called RS485Initialize which is like RS485Uart but it passes default values for the baud and mode parameters. I also added a function called UseRS485(). All it does is set the S4 port to SENSOR_TYPE_HIGHSPEED so that it can be used as an RS485 port.

I am in the process of improving some of the Remote* commands which can send direct and system commands from one NXT to another either via Bluetooth or RS485. Currently RemoteGetOutputState and RemoteGetInputValues have been modified to not only send the command to the remote NXT but to subsequently wait for a response (up to a maximum of ~500ms) and then process the response buffer to set output variables. Currently the signatures of these functions take several output variables but I may change this to pass in a structure which is modified and passed back out. That way you could pass in a variable of type OutputType which has fields called Power, Mode, RegMode, etc... (or something like that).

The changes to the API functions to wait for and process the response buffer are only available with the enhanced NBC/NXC firmware. The standard firmware version of these API functions just sends the command and does not try to wait or process the response, though it would not be impossible to do even with the standard firmware.

I also made some firmware changes related to my OutputOptions field in the Output module IOMap structure. It looks like the hold at limit option is working now, though it does not yet do a very good job of holding precisely at the specified tachometer limit. I need to do some more work on that.

http://bricxcc.sourceforge.net/test_releases/

John Hansen

[chanyh]

Problem 1 :
I use two NXT Bricks, one with FW NBC/NXC 1.31 and other LEGO NXT Firmware V1.29. The BicxCC is Version 3.3 (Build 3.3.8.9) and with test_release20101019. Both are under NXT 2.0 compatible firmware and Automatic firmware version.

When I execute the following program, it is OK for the LEGO NXT V1.29 firmware.

For the NBC/NXC 1.31, it shows "NXTDef.h Error line 8317, file “NXTDefs.h”: Error: Invalid label argument: wfRR Break".

Code: Select all

int count  = 0;
task main()
{
  while(true)
  {
    if (ButtonPressed(BTNRIGHT, true))
      count+=1;
    if (ButtonPressed(BTNLEFT, true))
      count-=1;

    // Check for not button pressed
    // Reset the press count (true) or not (false)
    until (!ButtonPressed(BTNLEFT, true)  && !ButtonPressed(BTNRIGHT, true));

    NumOut (20, LCD_LINE4, count, true);

     /* Wait for a "click" which is a press and release.
        Otherwise the code would cycle through the loop many times while you
        still have the button pressed. */
    Wait (25);
  }
}

Problem 2 :
I use the NXT Brick with FW NBC/NXC 1.31 to complile the following program "ex_RS485Send.nxc (the attachment in test_release20101019)"

Under the NXT 2.0 compatible firmware and Automatic firmware version. It shows "line 8317, file “NXTDefs.h”: Error: Invalid label argument: wfRR Break".

Then I change the preferences under the enchanced firware, it shows many errors.
1) "line 8313, file "NXTdefs.h":Error: Unknown or invalid statement",
2) "line 8320, file "NXTdefs.h":Error: Unknown or invalid statement",
3) "line 8317, file “NXTDefs.h”: Error: Invalid label argument: wfRR Break",
4) "line 30: Error: Error parsing expression : HS_BAUD_DEFAULT"
5) "line 38: Error: Error parsing expression : HS_BAUD_DEFAULT"
6) "line 64: Error: Error parsing expression : HS_BAUD_DEFAULT"

Code: Select all

// RS-485 sender program

inline void WaitForMessageToBeSent()
{
#if 0
  // using low level functions to wait for RS485 message to be sent
  bool sending, avail;
  RS485Status(sending, avail);
  while (sending) {
    Wait(MS_1);
    RS485Status(sending, avail);
  }
#else
  // use hi level API functions (preferred)
  while (RS485SendingData())
    Wait(MS_1);
#endif
}

task main()
{
  // configure the S4 port as RS485
  UseRS485(); 
  // make sure the RS485 system is turned on
#if 0
  // low level API function call
  RS485Control(HS_CTRL_INIT, HS_BAUD_DEFAULT, HS_MODE_DEFAULT);
#else
  // hi level API function call
  RS485Enable(); 
#endif
  // initialize the UART to default values
#if 0
  // low level API function call (allows changing UART settings)
  RS485Uart(HS_BAUD_DEFAULT, HS_MODE_DEFAULT); 
#else
  // hi level API function call
  RS485Initialize(); 
#endif

  Wait(MS_10);
  int i;
  while (true) {
    string msg;
    msg = "goofy ";
    msg += NumToStr(i);
    TextOut(0, LCD_LINE1, msg);
    SendRS485String(msg);
    WaitForMessageToBeSent();
#if 0
    // the RS485 receiver sample program is not written 
    // in a way to handle these additional messages
    // so do not send them (yet)
    RS485Write(msg);
    WaitForMessageToBeSent();
    SendRS485Bool(true);
    WaitForMessageToBeSent();
    SendRS485Number(i);
    WaitForMessageToBeSent();
#endif
    i++;
  }
  // disable RS485 (not usually needed)
  RS485Disable();
}

Can Mr.John Hansen help?


YH Chan

[afanofosc]

Later today I will upload a new test release which hopefully fixes these problems. Are you using the internal compiler or the external compiler? If you happen to be using the external compiler then I would recommend that you switch to using the internal compiler.

While I was at LEGO World I ran into an enhanced NBC/NXC firmware problem related to the motor control changes I had been testing. So all that has been backed out for the time being.

I also have fixed a compiler optimization bug when targeting the standard firmware. Technically it is caused by a bug in the standard firmware but now the optimizer works around that problem by not optimizing certain opcodes when the output argument is a float variable.

John Hansen

[chanyh]

I change to the internal complier, the two programs ex_RS485Send.nxc and ex_RS485Receive.nxc work and communicate with each other.

YH Chan

[afanofosc]

I looked at this today and it appears that I didn't update the nbc executable properly in the latest test release. My apologies. I will fix that tonight.

Unless you have a really good reason to use the external compiler I highly recommend that all BricxCC users of NBC/NXC switch to using the internal compiler. It is essential for Bluetooth communication to work with reasonable speed and by using the internal compiler you don't have to worry about accidentally pointing BricxCC to an old nbc.exe on your system.

John Hansen

[chanyh]

Referring to my post in 02 Nov 2010, 15:31 ("I change to the internal complier, the two programs ex_RS485Send.nxc and ex_RS485Receive.nxc work and communicate with each other"), I made a mistake in this statement. Very Sorry!

I select the internal complier and autiomatic firmware version, both. The two programs work. They are the attachments in the test_release20101019.

If I choose the internal complier singly, both programs shows many errors.
They are :
1) line 10: Error: Underfined Identifier RS485Enable;
2) line 10: Error: ';' expected;
3) line 10: Error: ';' Unmatched close parenthesis;
4) line 12: Error: Underfined Identifier RS485Initialize;
5) .....................................................
6) ...................................................
line 17: Error: Underfined Identifier RS485DataAvailable;
.............................................................
line 18: Error: Underfined Identifier RS485DataRead;
...............................................................




YH Chan

[afanofosc]

These API functions require the enhanced firmware so you will get compiler errors if you target the standard firmware. The header file has the function declarations surrounded by #ifdef __ENHANCED_FIRMWARE ... #endif. So if you have the automatic firmware version option checked and your brick actually has the standard firmware on it then these API functions will generate compiler errors. You'll also get compiler errors if you do not have the automatic firmware option checked and you do not have the enhanced firmware option checked.

The documentation for these functions should indicate that they require the enhanced NBC/NXC firmware.

John Hansen

[HaWe]

John,
I just downloadad the Nov test release, but unfortunately there are no release notes since June.
What has changed since then? (e.g., are the HT Tetrix muxers already supported?)

ps: 3.3.8.9 ? I only can find 3.3.8.8!