wishlist for NXC

[mightor]

You need to keep in mind that alien abduction phase way back when and the resulting affect it has had on my mental capacity.

So the goldfish brain transplant didn't work out as well as you'd hoped?

Support for direct commands via BT works well. However, how hard would be to have the same support for these calls through RS485? That would be quite powerful.

- Xander

[HaWe]

I am slowly making a connection between doc helmut and my old friend Ford Prefect. I know, I'm slow!

Ford Prefect? You mean the guy from somewhere in the vicinity of Betelgeuze...? hmmmh, what should I say - blissfully happy to hear he was a friend of U2 ;)

In any case, support for doubles is highly unlikely due to the substantial firmware changes that would be required. I don't see the ROI.

a real fine accuracy that you'll get e.g. if you add 6cm to an already driven distance of 1.800000 km?
Aaaahm, sorry, forgot you're an American ;)
add 2 inches to an already driven distance of 1 mile?
(BTW: LeJos and c++/nxtOSEK got double!) :)

Similarly, if it were easy to support recursion I would. Lacking any kind of local variable or stack-based variables or a call stack of any kind and given the design of the subcall opcode and the subret opcode there just isn't any way without huge changes to the firmware to support recursion. Maybe the compiler could be made to support a limited subset of recursive calls by unwinding the call in the compiler itself if I were much smarter than I am.

could be a high-range stack area (upper - let's say - 20 kByte) be an approach?
Used as an automatic called FIFO stack (for saving local variables) when a recursion is initiated similarily like the firmware does for time slices?

You need to keep in mind that alien abduction phase way back when and the resulting affect it has had on my mental capacity.
John Hansen

what have they done to your brain? Dissected it only, or even read poetry? *mmmpfggg*

[HaWe]

Support for direct commands via BT works well. - Xander

what direct BT commands? Did I miss something during the last 3 weeks?

[mightor]

Support for direct commands via BT works well. - Xander

what direct BT commands? Did I miss something during the last 3 weeks?

I was referring to the direct commands you can issue from a computer to an NXT to make it move the motors, that sort of thing. The way that software packages like PythonNXT and many others are able to remotely control the brick and its peripherals. I'd like that same interface exposed on an RS485 bus.

- Xander

[spillerrec]

a real fine accuracy that you'll get e.g. if you add 6cm to an already driven distance of 1.800000 km?
Aaaahm, sorry, forgot you're an American
add 2 inches to an already driven distance of 1 mile?

1.8 km + 6 cm works fine with single precision float (considering the base as cm). Do you have a real example where you experienced that floats where too imprecise?

[HaWe]

1.8 km + 6 cm works fine with single precision float (considering the base as cm). Do you have a real example where you experienced that floats where too imprecise?

you're completely right - my mistake. but try this one:

Code: Select all

task main(){
   float a= 180000000, b=6, c;
   NumOut(0,56,a);
   NumOut(0,48,b);
   NumOut(0,40,c=a+b);
   while(true);
}

Using long vs. int it works;
using float vs. double it doesn't.
but anyway - nxtOSEK got it, LeJos got it, there must be any sence in it.

@Xander:
aah, ok, thanks, I assumed there were already BT direct commands for motor control and sensor reading from 1 NXT to 1-3 slave nxts.

But that leads me back to Ford's old wish:
NXT-to-NXT BT commands like
BTonFwd(slaveNumber, portNumer, speed)
BTRotatemotorEx(slaveNumber, portNumber, .....)
BToff(slavenumber, portNumber)
BTcoast(slavenumber, portNumber)

BTsetSensor(slavenumber, portNumber, SensorType_or_I²Ctype)
BTsensorValue(slavenumber, portNumber, &sensorarray[])

and all that, as Ford wrote, "without any decyphering program running on any slave NXT"

and YES, I'd like to have all that for RS485, too:
RSonFwd(slaveNumber, portNumer, speed)
RSRotatemotorEx(slaveNumber, portNumber, .....)
RSoff(slavenumber, portNumber)
RScoast(slavenumber, portNumber)

RSsetSensor(slavenumber, portNumber, SensorType_or_I²Ctype)
RSsensorValue(slavenumber, portNumber, &sensorarray[])

[HaWe]

As I once wrote in the old nxtasy forum:
I think it would be fine to have a different syntax for sensor controlling:

Code: Select all

SetSensor(port, AnalogType_or_I²CType)
SensorValue(port, AnalogType_or_I²CType, &Values[])

[afanofosc]

I was referring to the direct commands you can issue from a computer to an NXT to make it move the motors, that sort of thing. The way that software packages like PythonNXT and many others are able to remotely control the brick and its peripherals. I'd like that same interface exposed on an RS485 bus.

Are you in a position to do some RS485 direct command experimentation? If so, send me an email.

John Hansen

[mightor]

Are you in a position to do some RS485 direct command experimentation? If so, send me an email.

John Hansen

I sure am. I have a couple of bricks I could use for this. If it works, you may see NXTerminator (my robot for Lego World) being reprogrammed in NXC, hehe.

I'll send you a mail in a mo

- Xander

[HaWe]

as I now ordered my TETRIX kit which I want to control by NXC of course:

I happily would appreciate if there will be a Servo and a DC encoder motor (multiplexer?) driver available