Page 2 of 2
Re: NXC RS-485 communication program problem
Posted: 12 Oct 2010, 20:13
by chanyh
Thanks, John.
I have a program which was adopted from the "Bricxcc". It sends a string "fine". If I send an integer, I use "NumToStr()".
If it changes to send an integer, how can I do?
The conditions are :
1) Use "SendRS485Number(const int value)" or others;
2) Not use "SendRS485String()";
3) Not use "NumToStr()"
Code: Select all
void SendRS485Message(const string msg)
{
byte mlen = ArrayLen(msg);
SetHSOutputBuffer(0, mlen, msg);
SetHSOutputBufferOutPtr(0);
SetHSOutputBufferInPtr(mlen);
SetHSState(HS_SEND_DATA);
SetHSFlags(HS_UPDATE); //send it
}
task main()
{
SetSensorType(IN_4, SENSOR_TYPE_HIGHSPEED);
SetHSState(HS_INITIALISE);
SetHSFlags(HS_UPDATE);
Wait(10);
while (true)
{
SendRS485Message("fine");
Wait(50);
}
}
YH Chan
Re: NXC RS-485 communication program problem
Posted: 13 Oct 2010, 03:03
by mattallen37
That "SendRS485Number(const int value)" refers to a void that is in the program, and in it, it uses "NumToStr()" to turn it into a string, and "SendRS485String()" to send the string. I think only strings can be sent, which isn't a problem. You can flatten a variable, and then send it, and unflatten it on the other NXT.
Re: NXC RS-485 communication program problem
Posted: 13 Oct 2010, 13:04
by jojoguy14
Ya...I've also been thinking if it's possible to make a custom NXT-G block for RS-485 commands. Does anyone have any documentation I could look at about RS-485? Does LEGO have a document? Has someone already tried to make this kind of block?
jojoguy10
Re: NXC RS-485 communication program problem
Posted: 13 Oct 2010, 16:24
by afanofosc
Please see the RS485 API functions in the NXC Guide and help files. The example files are not great, sadly, but they can be improved. The code posted above was written prior to the addition of the official API functions and they require the enhanced NBC/NXC firmware.
- rs485.JPG (89.79 KiB) Viewed 10593 times
When you send a number or a bool the API functions (which are called functions or procedures - not "void") flatten the data to a string. This is not the same as calling NumToStr. Calling NumToStr on a number will change 123456 into "123456" with a trailing null (0x00) terminator. 7 bytes of data. Using Flatten - which the SendRS485Number and SendRS485Bool functions do - will convert 123456 into a "string" containing 0x40, 0xE2, 0x01, 0x00, 0x00 (little-endian). 5 bytes of data. All numbers are flattened into a long (i.e., 4 byte) value plus a null. Bools are flattened into a single byte (0x00 or 0x01) followed by a null. This was done to adhere to the standard LEGO protocol used for sending numbers and bools via the mailbox system over Bluetooth.
You can, of course, use your own scheme for encoding and decoding messages you send via RS485 (or Bluetooth).
John Hansen
NXC RS-485 Direct communication 2 NXTs
Posted: 27 Oct 2010, 10:42
by spammyk
Dear all,
since it is possible to connect 2 NXTs via RS485 I have the following question.
In the code examples it is always just interchanging values.
When 2 NXTs are connected via bluetooth then it is possible that the master directly sends commands to access motors / sensors at the slave NXT.
Is this also possible using RS485? (Or if not... is it planned?)
Regards
Kai
Re: NXC RS-485 communication program problem
Posted: 27 Oct 2010, 16:51
by afanofosc
While at LEGO World and in the days prior to travelling I worked on enhancements to the firmware which would allow you to send direct and system commands from one NXT to another via either bluetooth or RS-485. I am still sorting out some brick hanging issues that I have encountered when processing incoming RS-485 data using the same "interpret" function that incoming bluetooth and USB data is fed through by default. If/when I get it working without problems then it will be exposed to NBC and NXC users with the enhanced firmware installed via Remote* API functions which take a connection number as the first parameter. Connections 0 through 3 are CONN_BT0, CONN_BT1, CONN_BT2, and CONN_BT3. Connection number 4 is CONN_HS4 and if you call an API function with that connection number it will attempt to communicate over RS-485 rather than Bluetooth.
Additionally, I am working on a minor change to the enhanced firmware which makes it always handle direct and system command responses rather than discarding all of them except for the MessageRead direct command (which is used by the firmware to handle reading a message from a remote NXT's response mailbox and writing it to the corresponding local NXT's mailbox). My initial thought (already partially implemented) is to copy the incoming direct and system command response data into a "last response" buffer that can be accessed via a new system call function that reads/clears the last response buffer. Using this new feature in conjunction with the RS-485 direct/system command processing changes, the intent is that all the existing direct and system commands will be supported, with those requiring a response actually waiting for the response to arrive and passing the relevant response data back to the user via the function call parameters.
I will almost certainly be adding more direct commands, as well, to expose more of the remote NXT's functionality to a "master" NXT so that you could also do things like output to the LCD. I'm considering adding a new API layer around existing API functions for reading sensor values and controlling motors so that you can do something like this:
Code: Select all
// control local motors
OnFwd(CONN_BT0, OUT_A, 75);
Wait(SEC_1);
OnRev(CONN_BT0, OUT_A, 75);
Wait(SEC_1);
Off(CONN_BT0, OUT_A);
// control motors on bluetooth connection 1
OnFwd(CONN_BT1, OUT_A, 75);
Wait(SEC_1);
OnRev(CONN_BT1, OUT_A, 75);
Wait(SEC_1);
Off(CONN_BT1, OUT_A);
// control motors on RS-485 connection 4 (device 0)
OnFwd(CONN_HS4, OUT_A, 75);
Wait(SEC_1);
OnRev(CONN_HS4, OUT_A, 75);
Wait(SEC_1);
Off(CONN_HS4, OUT_A);
In theory, with NXT's connected via RS-485 I could add a byte to the direct and system command protocol which would be a device ID/address byte so that you could connect more than one NXT as a remote slave over the hi-speed port and the direct/system command would only be processed by the slave with the specified device ID.
Does any of this sound interesting?
John Hansen
Re: NXC RS-485 communication program problem
Posted: 27 Oct 2010, 17:08
by HaWe
VERY interesting!
have you also some intentions to control motors by remote encoder targets or PID (like BTRotateMotorEx, RSRotateMotorPID) and to enable remote sensor setting and polling (like BTSetSensor, RSSensorValue)?
Re: NXC RS-485 communication program problem
Posted: 27 Oct 2010, 18:25
by spammyk
Hello John,
thank you for the fast answer and YES it sounds great!!!
And I value it a lot that you develop that kidn of things for the mindstorm community.
How will you announce news / new functions implemented to NXC?
Kind regards
Kai
Re: NXC RS-485 communication program problem
Posted: 27 Oct 2010, 23:09
by jojoguy14
John,
Awesome! I was planning on making a Guitar Hero playing robot, but I needed two NXT's and using bluetooth, it would be too slow. So, this'll make me want to learn how to code in C and learn how to use Bricxcc!
Thanks a bunch!
jojoguy10