NXC: set / change Brick name?

[HaWe]

+1
same issue for my BT network where the slaves start a specific code which works only with a specific BrickName.
If one brick intermediately has been exchanged by another one e.g., because of a damage, one could transfer the code to the new one which also sets his name to become correctly addressed by the master.

BTW
What's the command for a program to get (read) the current brick name?
I expected sth like

Code: Select all

string GetBrickName()
or
string GetBTName()

but found nothing like that.

The equivalent to set the brick name should be

Code: Select all

SetBrickName(string name)

[afanofosc]

I use Get at the start of a name only if you return the value via a reference parameter. If it returns the value as a function result I drop the word "Get". For example, SetSensorType and SensorType. SetBrickDataName and BrickDataName. Though, as was discussed, I dropped SetBrickDataName from the NXC API when I realized that it did not actually persist the name. "BrickData" comes from the name of the field (a nested structure) in the Comm module IOMap structure which contains all of the BRICKDATA values, including the brick's name.

John Hansen

[HaWe]

why BrickDataName and not BickName? The latter would be more intuitive.

Also in general, if there is a "SetXYZ" or "WriteXYZ" to set or write a value, the equivalent would be intuitively "GetXYZ" or "ReadXYZ" to get or read the value.

who did once define the names in the IO map?
you or Lego?

[afanofosc]

You are welcome to write your own NXCDefs.h (named something different, of course) and tell the compiler to ignore the system include files. In fact, I encourage you to do that!

LEGO/NI are the culprits when it comes to the names of fields in the module IOmaps. I mostly tried to use the names they provided. Personally I don't think API names are intuitive. You just have to learn them and remember them. Why not NXTName rather than BrickName? Or just Name? or BluetoothName? Or BTName? Well, in any case, the function is called BrickDataName and you can use it or #define your preferred alternative name if you like.

Code: Select all

#define BrickName BrickDataName

Do that and then you can use BrickName() to return a string containing the NXT's name whenever you need it. You will not succeed in persuading me to change the NXT API.

I have made the firmware changes recommended above and will be testing them a bit before putting up a new firmware build.

John Hansen

[HaWe]

if I knew what keywords I had to use I certainly had the chance to search for them
Of course I have been searching "intuitively" for
BrickName
NXTName
BTName
but found nothing in the BCC help. So what else should one do?
When I once knew it then I surely can use it as it is (BrickDataName) - as long as I would remember and won't forget - and for that (short) period I wouldn't need a #define alias of course.

[afanofosc]

When you search in the NXC API search field you start with one letter. It shows you what matches that single letter. So start with the intuitively obvious B if you think the right function name is BrickName. Maybe even type Brick all at once. Low and behold you see a very short list of functions that start with Brick and they all have Data as the next part of the name. One of them is BrickDataName. Or you can start with BT and see a longer list that you can easily scroll through and see that there is not a function called BTName. Or you can type in NXT and scroll through the list of constants and functions that start with NXT.

It takes all of a few seconds to find what you are looking for using the NXC API search field. If you weren't sure what API functions let you "set" something to do with a "sensor" you start with "Set" and see what shows up. It is actually case insensitive so you could just type setsensor or even just sets. You can even limit the search to just functions using the drop down menu at the right of the search field.







John Hansen

[HaWe]

ok, I see, I never won't use the help search (by [F1] ) any longer...

[HaWe]

edit:
strangely, this code causes errors:

Code: Select all

char PMOD;
if (BrickDataName()=="001") PMOD=1;

if I store intermediately to a buffer, it seems to compile strangely:

Code: Select all

char PMOD;
string name;
name=BrickDataName();
if (name=="001") PMOD=1;

but the returned name string also seems to be sort of distorted.

with this code

Code: Select all

 task main(){

  string name = BrickDataName();
  TextOut(0,0,">"+name+"<");
  while(true);
}

the screen output is

>001

and not, as expected,

>001<

[mattallen37]

It seems that BrickDataName() returns the name, padded to 15 chars (Edit: plus the NULL). Using strlen on the string returned by BrickDataName returns 15. Probably the reason you didn't see the "<" was because it would have been displayed off the screen.

[HaWe]

yes, sure that there must been some invisible characters like space or anything.
But that's faulty, that's what I wanted to point out.
BrickDataName has to return the correct name as it is, either how long it is, and just how long it is exactly .