View unanswered posts | View active topics It is currently Mon Nov 24, 2014 4:19 pm






Reply to topic  [ 22 posts ]  Go to page Previous  1, 2
Problems with sensor testing in 1.40 public RC1 
Author Message
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
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!

_________________
regards,
HaWe aka Ford
#define S sqrt(t+2*i*i)<2
#define F(a,b) for(a=0;a<b;++a)
float x,y,r,i,s,j,t,n;task main(){F(y,64){F(x,99){r=i=t=0;s=x/33-2;j=y/32-1;F(n,50&S){t=r*r-i*i;i=2*r*i+j;r=t+s;}if(S){PutPixel(x,y);}}}while(1)}


Thu Jul 31, 2008 7:50 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: Problems with sensor testing in 1.40 public RC1
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.


Wed Aug 13, 2008 2:00 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: Problems with sensor testing in 1.40 public RC1
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;
Code:
const tMotor motorLeft = motorA;
const tMotor motorRIght = motorB;

motor[motorLeft] = 50;
motor[motorRight] = 50;

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.


Wed Aug 13, 2008 2:14 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post Re: Problems with sensor testing in 1.40 public RC1
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.


Wed Aug 13, 2008 2:18 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post Re: Problems with sensor testing in 1.40 public RC1
Dick Swan wrote:
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;
Code:
const tMotor motorLeft = motorA;
const tMotor motorRIght = motorB;

motor[motorLeft] = 50;
motor[motorRight] = 50;



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:
Code:
const tMotor motorLeft = motorA;
const tMotor motorRight = motorB;

task main(){
  motor[motorLeft] = 50;
  motor[motorRight] = 50;
}


This will produce:
Quote:
*Warning*:Variable 'tMotor' declaration must be qualified with type. Type 'short' used.
**Error**:Constant variable 'tMotor' must have initialization expression
**Error**:Expected->';'. Found 'motorLeft'
**Error**:Undefined variable 'motorLeft'. 'short' assumed.
**Error**:Executable statements not valid in 'main' declaration block
*Warning*:Variable 'tMotor' declaration must be qualified with type. Type 'short' used.
**Error**:Constant variable 'tMotor' must have initialization expression
**Error**:Expected->';'. Found 'motorRight'
**Error**:Undefined variable 'motorRight'. 'short' assumed.
**Error**:Executable statements not valid in 'main' declaration block


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


Wed Aug 13, 2008 2:26 am
Profile
Creator
Creator

Joined: Fri Feb 09, 2007 9:21 am
Posts: 615
Post Re: Problems with sensor testing in 1.40 public RC1
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.


Wed Aug 13, 2008 3:02 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post Re: Problems with sensor testing in 1.40 public RC1
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. :D
Again, thanks for the reply.


Wed Aug 13, 2008 4:15 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 22 posts ]  Go to page Previous  1, 2

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  



Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.