Page 1 of 2

NXC RS-485 communication program problem

Posted: 08 Oct 2010, 15:49
by jojoguy14
Hello,

I have the NXT Power Programming Second Edition book by John Hansen. There are 2 different programs on how to communicate with RS-485 (in the NXT's 4th input port). The receiver program compiled fine, but the sender program has a few errors.

Code: Select all

// RS-485 sender program
task main()
{
     SetSensorType(S4, SENSOR_TYPE_HIGHSPEED);
     SetHSState(HS_INITIALISE);
     SetHSFlags(HS_UPDATE);
     
     Wait(10);
     int i;
     while (true) {
           string msg;
           msg = "goofy " ;
           msg += NumToStr(i);
           SendRS485String(msg);
           WaitForMessageTobeSent();
           i++;
     }
}
The errors occur in the "SendRS485String(msg); (line 14)" line and the "WaitForMessageToBeSent; (line 15)" line. The errors are:

Line 14: undefined identifier SendRS485String
Line 14: ';' expected
Line 15: undefined identifier WaitForMessageToBeSent
Line 15: ';' expected
Line 15: Unmatched close parenthesis

Can someone give me a push in the right direction on how to figure this out? I'd like to begin learning NXC (since I'm getting better with other programming languages).

Thanks,

jojoguy10

Re: NXC RS-485 communication program problem

Posted: 08 Oct 2010, 17:29
by mattallen37
Be sure you have the latest NXC release, and that the compiler settings match your firmware.

Instead of the wait until sent command, I use the following.

Code: Select all

while(HSOutputBufferOutPtr() < HSOutputBufferInPtr()){Wait(1);}
The WaitForMessageTobeSent(); doesn't seem to be a command, and obviously won't compile for me. I think it was just a line of code used to refer to a void that doesn't exist in your program.

The SendRS485String(msg); command is fine.

Re: NXC RS-485 communication program problem

Posted: 08 Oct 2010, 18:49
by jojoguy14
IT WORKS! THANKS! :D

jojoguy10

Re: NXC RS-485 communication program problem

Posted: 08 Oct 2010, 18:54
by mattallen37
With few exception, if there is ever a "command" that is not blue, it is not a predefined command, and must be supported by a custom built void. If there is code that you know should compile, but it doesn't, then I suggest you confirm you have the latest BCC, and proper compiler settings.

Re: NXC RS-485 communication program problem

Posted: 09 Oct 2010, 03:44
by afanofosc
The code from the book should have the word "be" capitalized and the entire program should look like this:

Code: Select all


// RS-485 sender program

inline void WaitForMessageToBeSent()
{
  while(HSOutputBufferOutPtr() < HSOutputBufferInPtr())
    Wait(1);
}

task main()
{
  SetSensorType(S4, SENSOR_TYPE_HIGHSPEED);
  SetHSState(HS_INITIALISE);
  SetHSFlags(HS_UPDATE);

  Wait(10);
  int i;
  while (true) {
    string msg;
    msg = "goofy ";
    msg += NumToStr(i);
    SendRS485String(msg);
    WaitForMessageToBeSent();
    i++;
  }
}

My apologies if there are errors in the book's presentation of this program.

John Hansen

Re: NXC RS-485 communication program problem

Posted: 09 Oct 2010, 22:41
by mattallen37
So it is a user defined void as I suspected. What I do is just use the code run in the void, as it is only one line (or two with the optional wait), and take out the void completely.

Re: NXC RS-485 communication program problem

Posted: 12 Oct 2010, 17:56
by chanyh
Can someone help?

What is the meaning of " while(HSOutputBufferOutPtr() < HSOutputBufferInPtr())
{Wait(1);}"

Re: NXC RS-485 communication program problem

Posted: 12 Oct 2010, 18:01
by mattallen37
That is not exactly right, but what it means, is that the message needs to be sent before it will continue past the command.

Re: NXC RS-485 communication program problem

Posted: 12 Oct 2010, 19:03
by afanofosc
What is the meaning of " while(HSOutputBufferOutPtr() < HSOutputBufferInPtr())
{Wait(1);}"
As the NXT firmware goes about sending data out over the RS-485 (HS) port it increments the HSOutputBufferOutPtr. There is data waiting to be sent as long as HSOutputBufferInPtr is > HSOutputBufferOutPtr. The operation is asynchronous, i.e., your program will move on to the next statement even though the data has not actually been transmitted yet. It happens behind the scenes while your program continues onward. Because you don't want to fiddle with the contents of the high speed (HS) output buffer while it is still trying to send the last bit of data you told it to transmit you need to have your program wait until the last send operation finishes before you try starting another send operation. This kind of situation is exactly like sending data over Bluetooth or to an I2C device. In all three of these cases you give the firmware some data to send and then you need to wait in your program until the firmware finishes that task. You can guess at how long it takes, possibly under or over estimating, by using Wait(ms) but that's not a good idea. Instead you use the API functions that tell you the status of the last operation and try to minimize the amount of time your program spends waiting.

John Hansen

Re: NXC RS-485 communication program problem

Posted: 12 Oct 2010, 19:55
by HaWe
John, please do not take it personally, but I have 2 suggestions:

1st, I think "Highspeed (HS)" is not a good term for the RS485 serial protocol.
I²C already may work with different bus speeds (RobotC uses this feature), and so IMHO "Lowspeed" and "Highspeed" should be I²C terms.
RS485 is a serial COM protocol, I would suggest to call it "RS" instead of "HS"

2nd, I know (and really appreciate) how much work you've done for developing NXC, but just RS485 (and BT) is really too complicate to handle for beginners - at least (or even) for me, nevertheless I meanwhile made some minor progress. Maybe you manage to simplify RS485 and BT commands: adjust the syntax to each other and let them do all the waiting and connecting and clearing automatically?
Like
RSSendMessage(slaveNumber, MsgString) // sends when bus is cleared and waits until the msg has been received and confirmed by the slave
BTSendMessage(slaveNumber, MsgString) // see above

Motor and sensor control commands (BT, RS) might be defined by a similar scheme or pattern.

(Actually this is an issue for the wish list)

kind regards,
Helmut