View unanswered posts | View active topics It is currently Wed Aug 20, 2014 12:53 am






Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Problems with sensor testing in 1.40 public RC1 
Author Message
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post Problems with sensor testing in 1.40 public RC1
I was testing the public RC1 yesterday and really like some of the new features. Before I was running 1.10 with the appropriate firmware. Because some new test functions (i.e. for acceleration sensor) where included, I wanted to make use of them. Unfortunately the NXT keeps telling me "Bad version!". I tested with acceleration and sonar sensor in particular, but also tried to use the other test buttons without attaching the appropriate sensor with the same result. Also I tested the view function on NXT and found the sonar sensor stuck at a value of 253. The light sensor is working in view-mode (it didn't test more sensors). Is this a bug of the firmware?

By the way, the program I was running in 1.10 without compiler errors, now produced a bunch of it. In particular he was complaining something with the line (I didn't pass to the other errors so far):
Code:
const tMotor primM = motorB; // primary motor

Was there any change with the type "tMotor"?


Wed Jul 23, 2008 1:37 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
hi, concerning tmotor, this is what I found:
Code:
typedef enum// Specifies a single motor
{
  motorA         =  0,
  motorB         =  1,
  motorC         =  2,
  motor00        =  3,
  motor01        =  4,
  motor10        =  5,
  motor11        =  6,
  motor20        =  7,
  motor21        =  8,
  motor30        =  9,
  motor31        = 10,
} tMotor;

does this help?

BTW:
I prefer to use the direct port addresses, or variables, not constants, e.g.
Code:
int primMotor;
motor[1]=100;
//or
primMotor=1;
motor[primMotor] =100; // instead of tMotor motorB


To me, this is more "C-like", more strict and straight, and actually more "simple and stupid".
Additionally, if you use numbers instead of const names, you may increment and calculate with those by for- and while-loops (sorry for my poor English):
Code:
int i;
for (i=0;i<=2;i++) {
   motor[i]=100;
}

(just my 2ct)

_________________
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)}


Wed Jul 23, 2008 6:02 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
Thanks for the answer. Interesting to know. Where did you find the definition?

The error messages I get are as follows:

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


These are just generated when including the line:

Code:
const tMotor primM = motorB;


The warning can be simply overridden by adding type "short" in front of "tMotor". All the other errors seem to originate from some declaration syntax he doesn't like.
But the same code was working perfectly with RobotC 1.10!? Any ideas?


Wed Jul 23, 2008 7:08 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
what happens if you erase "const" and write:
Code:
tMotor primM = motorB;
:?:

but, again, why do you use tMotor at all? It's just an Integer, why don't you use an integer?
Code:
 const int primM=1;
// or
int primM=1;



To my opinion, this seems to be a bug, maybe you wish to report this to the bug tracker.
Let's see, what the developers will respond to this... ;)

_________________
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)}


Wed Jul 23, 2008 8:13 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
Removing "const" results in one error message less than before (the first error message is suppressed).

Why using this at all? First, its a way of keeping the code more readable. Second, I don't mind using it or not. I just copied from one sample program and had the opinion that it should keep working also in the new version of RobotC, which apparently is not the case. So I just wanted to clarify, because I want to understand what is happening (the only way to learn the language).

Before reporting this as a bug, I wanted to make sure its not just a mistake by me. Although I have experience with programming, I'm still a beginner in terms of RobotC.

Thanks so far. Any further comments are welcome.


Wed Jul 23, 2008 8:47 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
Using
Code:
const tMotor primM = motorB; // primary motor
there is not such an error message with neither the 1.38 nor the 1.22.
There wasn't any change with the type "tMotor" till 1.38.
But there are meanwhile more compiler "errors" by newer releases, where there haven't been any with earlier ones.

Plz send us the complete original source code to check it out.

BTW: did you completely remove the 1.10 before you installed the 1.40, and did you download the associated firmware (because of the "bad version")?

_________________
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)}


Last edited by Ford Prefect on Thu Jul 24, 2008 2:24 am, edited 2 times in total.



Wed Jul 23, 2008 5:32 pm
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
Ford Prefect wrote:
BTW: did you completely remove the 1.10 before you installed the 1.40, and did you download the associated firmware?


Of course I did. In fact it has nothing to do with the firmware on the NXT. This is a pure compiler issue. I discovered so far that "tMotor" is no longer accepted as variable type. Therefore you could simply declare anything with "tMotor" and get these error messages, e.g.:

Code:
const tMotor primM = motorB;

task main()
{
  // nothing to do
}


If you simply exchange "tMotor" by for example "short" everything is fine. As you already explained this will make no difference in the program anyway. So this is a simple workaround. I just wonder if it was intended to remove "tMoter" as type declaration?

BTW: Anybody discovering theses "bad version"-messages when using the sensor-test-functions under 1.40 public rc1?


Thu Jul 24, 2008 1:58 am
Profile
Moderator
Moderator
User avatar

Joined: Wed Jan 31, 2007 3:39 am
Posts: 299
Location: San Diego, California. USA
Post 
Hi Zeron,

The correct declaration should be this:

const tMotor NewNameHere = (tMotor) motorA;
const tMotor NewNameHere = (tMotor) motorB;
const tMotor NewNameHere = (tMotor) motorC;

Tmotor is a fixed variable in RobotC, it should not be changed. The reason is the motors and sensor setup wizard uses this variable. Try experimenting with this wizard by going to Robot in the upper menu and selecting the Motors and sensors wizard. This wizard lets you give motors or sensors simple names to use in your program, so you don't have to always use motorA or S1 S2. You can name the port LeftMotor or RightLightSensor.

It looks like an older wizard or compiler may have generated some bad syntax that has been fixed in the newer release.

Hope this helps, let me know if this works.
Scott B-)

_________________
Mmmm Legos B-)

My Robot Projects:
http://www.freewebs.com/robotprojects/


Thu Jul 24, 2008 3:31 am
Profile WWW
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
Thanks for the suggestion.
For testing, I setup a motor on port B, which then generated the code:
Code:
#pragma config(Motor,  motorB,          primM,                tmotorNxtEncoderClosedLoop)
//*!!Code automatically generated by 'ROBOTC' configuration wizard               !!*//


Interesting feature! This way the declaration I used before is not needed anymore! Anyway, the code causing the error I retrieved from one of the examples which are delivered with RobotC. The typecasting "(tMotor)" doesn't help at this point. Really seems to me as if this type is no longer valid. Maybe it is intended.


Thu Jul 24, 2008 3:48 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
I got feedback from the developers via the bug tracking page. Here is what they told.
Regarding the "tMotor"-problem:

Quote:
You should use the Motors and Sensors Setup window under the "Robot" menu to assign variables names to motors. The whole definition system has switched from 'const' statements to "#pragma" statements.


As I've already assumed, this kind of declaration is no more valid. Regarding the sensor-test function I got the following info:

Quote:
This has been fixed and will be released in either RC2 or the final version.


BTW: Can any moderator or admin delete this spam-bot "micky0604", please?


Wed Jul 30, 2008 10:17 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
hi,
I don't think it's a good idea always to setup motors and sensors by the automatically generated code.

1st, because I hate automatically generated codes. They could put header files and libraries to the examples, so that everybody can read the code and include it if he wants (or not), but please no hidden functions, no automatics, and no "code optimization" beyond the programmer!
2nd, because manual assignment of I/Os is the usual way of programming (and this is even better for "educational" intentions).
3rd, because code portation to other C platforms (such as NXC and even a ATMEGA32 or renesas C) is much easier if you have your own private ways of assignments, and those common C compilers NEVER have automatic generated code.

so, what should this be for ?

_________________
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)}


Last edited by Ford Prefect on Wed Jul 30, 2008 11:57 am, edited 1 time in total.



Wed Jul 30, 2008 10:31 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
As you can see in one of my former posts, there is still some manual declaration possible (without using the dialog):

Quote:
#pragma config(Motor, motorB, your_var_name, tmotorNxtEncoderClosedLoop)


This should do the job. Of course, more documentation about #pragma definitions would be appreciated.


Wed Jul 30, 2008 11:24 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
how will you tell a NXC or a renesas or a Atmega 32/128 C compiler to compile this ?
(back to the C roots!)

_________________
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)}


Wed Jul 30, 2008 11:47 am
Profile
Guru
User avatar

Joined: Sat Mar 01, 2008 12:52 pm
Posts: 1030
Post 
PS:
this is the C code which a "real C compiler" (renesas C) uses to switch on outputs (motors) and to get sensor inputs:.
Code:
   
  sTrans.MPWM_Main[0] = 8;      // PWM for Output O1
  sTrans.MPWM_Update = 0x01;  // Update PWM values every 10ms
  sTrans.M_Main = 0x01;           // switch Output O1 ON
  sTrans.M_Main = 0x00;           // switch Output O1 OFF
  sTrans.E_Main & 0x01           //Touch Sensor E1


To make this readable, you surely will have to write macros and functions like
Code:
void motor(portnumber, pwm)
int sensor(portnumber, sensortype, valuemode)

(or use such functions enclosed in some libraries) which encode these "close-to-hardware" commands.
By routines like these, motor and sensor control can simply be adapted to the current hardware.
Code:
 
#include    "TA_Firmware\TAF_00D.h"
#include    "TA_Firmware\TAF_00P.h"

UCHAR main(void)
{
   
    sTrans.MPWM_Main[0] = 8;    // PWM for Output O1
    sTrans.MPWM_Update = 0x01;  // Update PWM values every 10ms

    do
    {
        sTrans.M_Main = 0x01;       // switch Output O1 ON
        FtDelay(500);               // Wait 500ms
        sTrans.M_Main = 0x00;       // switch Output O1 OFF
        FtDelay(500);               // Wait 500ms
    }
    while ( (sTrans.E_Main & 0x01) == 0);   

    return (0);               
}


THIS is "REAL C" - this is the way RobotC is expected to work!
What Robot"Fantasy"C does is not "real C": it's sometimes easier, sure, but mostly it's unfathomable and unpredictable !

_________________
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 6:07 am
Profile
Rookie

Joined: Wed Jul 23, 2008 12:48 am
Posts: 19
Location: Germany
Post 
But this is the way RobotC works. And to my opinion it is fine anyway. I'm used to adapting code when running on other machines or compilers. But I understand your complains. Nevertheless the more I work with RobotC the less I feel, the compiler does things, which I can't control. I think it just needs some more polishing and bug-fixing. Why not just switching to another language, if you find one that fits your needs better than RobotC? Is "rensas C" something which can be used for the NXT?


Thu Jul 31, 2008 7:19 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 22 posts ]  Go to page 1, 2  Next

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.