Trig functions in NXT-G

[mightor]

Is there a particular reason why you want to limit yourself to using NXT-G ?
NXT-G might not always be the best choice for advanced use cases.

I just wanted to see if I *could* No specific reason.

- Xander

[mpscholz]

I just wanted to see if I *could*

I see - “Because it is there”

Just in case a non NXT-G, non-standard firmware platform is an option for you (you will forgive me deviating somewhat from the original thread subject, won't you?) : leJOS NXJ, for instance, offers a variety of trigonometric functions in its Math API (http://lejos.sourceforge.net/p_technolo ... /Math.html).
As far as I know, also NXC does.
I'm not aware of their actual execution speed, though.

[mightor]

I already have it working quite nicely in ROBOTC. Perhaps Lejos or NXC would be a nice option to try.

- Xander

[schodet]

Is it possible to add a new block to NXT-G for new opcode? Do you know how new blocks are made (those for new sensors for example)?

[gloomyandy]

Taking this even further off topic. leJOS supports both float (32 bit) and double (64 bit) floating point but the trig functions are all double versions (as per standard Java). Interestingly it implements these functions in Java rather than directly in the firmware (this was done mainly to keep the leJOS firmware small, and because we could!). It would be kind of interesting (in a language implementers view of interesting) to compare how these various versions compare for speed and accuracy .

Getting slightly back on topic, the leJOS implementation might be of interest to anyone that wanted to create their own functions. I think the implementation is a pretty good one...
http://lejos.svn.sourceforge.net/viewvc ... iew=markup

[hassenplug]

Is it possible to add a new block to NXT-G for new opcode? Do you know how new blocks are made (those for new sensors for example)?

The opcodes are in the firmware. We can't add new functionality to the firmware, from a program.

New sensors simply use existing opcodes. Usually, the sensor has different functionality internally.

Steve

[schodet]

The opcodes are in the firmware. We can't add new functionality to the firmware, from a program.
New sensors simply use existing opcodes. Usually, the sensor has different functionality internally.

So the only possibiliy is to use an existing interface to execute new opcodes.

[mightor]

The opcodes are in the firmware. We can't add new functionality to the firmware, from a program.

Steve,

I think what he meant was can you make a block that uses an opcode in the enhanced firmware. That would also be a nice solution.

- Xander

[afanofosc]

The NXT-G compiler is like the NBC compiler with respect to which opcodes it recognizes and can put into an executable. New opcodes require a compiler change.

The firmware has a bunch of "system calls" which could be dynamically supported in the NXT-G compiler but as far as I know the compiler still uses a hard-coded list of possible system call function numbers and it doesn't know how to use a system call that is not in its list. The NBC compiler doesn't check the system call number you pass to the syscall opcode and it doesn't check the type of the structure you pass to it either so it is possible with NBC to support newly added system call functions in a modified firmware without requiring a compiler modification.

John Hansen

[schodet]

So what can be done with new NXT-G blocks, is "MyBlock" the only solution (build blocks from other blocks), or is there anything else?