hello,
no, renesas C is a compiler just for renesas µC's, e.g. in the Fischertechnik Robo Interface (M30245), it won't work with the atmel ARM µC.

And it's a compiler which produces mashine code (like assembler), not a byte code interpreter like RobotC.

On the other hand, also the atmega32/128 C compilers are real C compilers (not interpreters), but these ones only do work with the atmel atmega32 or the atmega128, and they also won't work with neither the ARM nor the renesas M30245.

But for this purpose the C language is just fine : source code portability to any a platform, any source may be compiled with the same result, just with the hardware specific C compiler, and this is because of ANSI standard syntax and ANSI standard I/O routines (e.g., ANSI C99).

Unfortunately, really "real C" ANSI standard compilers for the nxt are currently not available at all.
If even RobotC keeped the ANSI C standards, all could be fine!

The original problem with "Bad Version" is a mismatch of the version stored in the firmware vs the version stored in an executable program file (i.e. file type "rxe" on the NXT). In one of the interim releases I failed to recompile the Try Me programs and they all failed with this problems. You'll also get this error if the firmware version is out of sync with the ROBOTC PC application version since the version in the "RXE" file comes from the PC version.

This integrity check is needed because different versions are not guaranteed to be upwards / backwards compatible.

Responding to another item in the thread.

Whether you use numeric index, or enum, or user assigned name for motor is a matter of personal preference.

The vast majority of end user feedback was that "motorA" was preferred over "0". And it does correspond to the A, B, C naming convention adopted by LEGO.

My personal preference is a user defined descriptive name;

ROBOTC has been recently enhanced to support the HiTechnci "accessory" motor controllers that connect to sensor ports and provide control over two new 12V motors. This is part of the kit for the new FIRST FTC robots. Up to four motor controllers (or hubs) can be daisy chained to each sensor port.

I agree that a enun like "motor_S1_C3_1" to indicate the first motor on the third controller connected to sensor port is a little confusing. But it is a heck of a lot less confusing than knowing this is motor index "8". Of course this is why I personally prefer the user defined name approach described in the above code example.

Regarding the Try Me function: It works fine with 1.40 public RC2 now, thanks. By the way, I like the Try Me program of the accelerometer. Nice one.

This is exactly the way I was doing with version 1.10. Unfortunately, in 1.40 public RC1 and RC2 "tMotor" is no more accepted as variable type. Just try your simple example in full context:


This will produce:


But you can exchange "tMotor" by "short" and it works just as before.

tMotor definition is definitely broken.

Yes. The definition of "tMotor" is broken in the recent 1.40 pre-release. It is fixed in 1.41.

In advance of 1.41 you can fix it yourself. Change "TMotorIndex" to "tMotor" in the file "RobotcIntrinsics.c" found in the "Include" sub-folder in the RobotC install directory.

The problem arose because there are several conditional declarations of "tMotor" based on the platform that is being selected. When adding changes for the new FTC platform, the name inadvertently got renamed.

Ahh. Thanks for pointing that out. From the feedback I got via the Bug-Tracker, I thought "tMotor" was removed intentionally and should not be used anymore. Now, I'm happy again.
Again, thanks for the reply.