Quote:
Originally Posted by PhilBot
2) Sorry team 288, but your Dead-Zone scaling is a major CPU hog, and on my NXT it introduces a very noticable delay. I suspect that it's the floating point divide and two floating point multiplies. Without a floating point processor, divides can take a long time.
|
The "standard" NXT-G firmware (i.e. version 1.05) does not support floating point variables. FTC uses a special version of NXT-G firmwre (version 1.21); I don't know whether this has changed fror it.
The LabVIEW toolkit for NXT compiles your program into a object file for execution on the NXT. It does not warn you about the lack of floating point.
In any case, floating point calculations on the NXT are quite fast. They take 5 to 15 microsecnds depending on the operand -- division is the slowest. This is inconsequential for this particular application.
- The PC application only scans the joysticks at a 50 millisecond rate!
- The NXT's Virtual Machine that interprets the "object code" takes 40 microseconds or more for simply opcodes.
- The NXT communicates with the Motor Controller over a slow I2C messaging link. It takes 5 to 10 milliseconds to send a message.
ROBOTC does support floating point variables. And its I2C messaging to the Motor Controller runs 3 to 5 times faster than NXT-G.
So it is unlikely that floating point calculations are the culprit.