printf isn't printf-ing. Help!

[Meandmyself]

the wierdest thing is happening. When I do this;

  /*way up at the beginning of the file...*/
  char counter = 0;

  /*in process_data_from_master_uP*/
gyroin = get_analog_value(rc_ana_in_01);
if (counter > 40) {
     printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));
     counter=0;
}

counter++;

printf prints out nothing. But this:

printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));

works fine. What's going on here?

BTW, this is all happening in the context of a larger problem that is I can't get the Gyro from last year to send values to the Edubot. When it does print, it says 0,0 no matter what.

It also has never printed the initialization message in user_initialization(). What's up with that?

[Dave Flowerday]

Originally Posted by Meandmyself

  /*way up at the beginning of the file...*/
  char counter = 0;

  /*in process_data_from_master_uP*/
gyroin = get_analog_value(rc_ana_in_01);
if (counter > 40) {
     printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));
     counter=0;
}

counter++;

Is "counter" a global variable? Put a printf outside the "if(counter > 40)" line and see if counter is ever actually greater than 40. I suspect that's where your problem lies.

[The Lucas]

just put:

extern char counter;

in your header file (user_routines.h). This will make counter a global varable that stays in memory

[Mark McLeod]

Originally Posted by Meandmyself

the wierdest thing is happening. When I do this;

/*way up at the beginning of the file...*/
char counter = 0;
 
/*in process_data_from_master_uP*/
gyroin = get_analog_value(rc_ana_in_01);
if (counter > 40) {
printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));
counter=0;
}
 
counter++;

printf prints out nothing. But this:

counter never gets higher than 1 in your version, and you have a problem in your printf as well.
Do this instead.

/* all in process_data_from_master_uP*/
static char counter = 0;
 
gyroin = get_analog_value(rc_ana_in_01);
if (counter > 40) {
printf("%d, %d \n", (int)gyroin, (int)get_analog_value(rc_ana_in_01));
counter=0;
}
counter++;

[Meandmyself]

All those are great suggestions, but I think the problem is deeper than that. I noticed today that the program state light stays yellow when I download. I tried changing around a few things, such as the last function I added. I ditched the if counter>40 thing, and just printfing every time doesn't even work.
Basically, this is the last function I added since it stopped working:

void findcurrentpos(void)	/*basically takes input from yaw rate sensor and integrates to find how much the direction has changed*/

{
current.theta += ((gyroin + gyroprev - 1023) * CGYRO * deltat) + 2000;		/* finds our current direction  cgyro converts to degrees/100, find average and multiply by time, dt converted to seconds by dt/1000*/

	deltat = 0;     /*modified in user_routines_fast with the internal timer*/

//	if (current.theta < 2000) {current.theta += 36000;}
//	current.theta -= 2000;
//	if (current.theta > 360) {current.theta -= 36000;}
//	gyroprev = gyroin;

}/*end findcurrentpos()*/

(CGYRO = 0.08)

And this gives me either an overflow error, or the Program State LED on the Edubot blinks red. In the Edubot reference guide a blinking red light means an infinite loop.

However, a funny thing happens when I comment out all the code in findcurrentpos(), It works! no blinking red light, no overflow error. I wonder if there is a limit for how large a math operation can be. I know on my calculator, if you multiply two very large values, you can get an overflow error. I also had another problem with a sin approximation giving an overflow error. I just replaced it with a lookup table. If there is such a limit, what is it?

[Joe Ross]

As others have said, using floating point calculations on the PIC is like playing with fire.

[Mark McLeod]

Any chance you're running out of program/data space?
That's one of the reasons you'll get the yellow light.
Using the .08 value drags in additional s/w to perform floating point processing.

What type is "current.theta" and what's a sample maximum deltat value?

[Meandmyself]

Originally Posted by Mark McLeod

Any chance you're running out of program/data space?
That's one of the reasons you'll get the yellow light.
Using the .08 value drags in additional s/w to perform floating point processing.

What type is "current.theta" and what's a sample maximum deltat value?

Yeah, I think the math is getting a little too big and the Pic can't work with numbers that big. I had the same problem before when I tried to raise a float to the fifth power. What I can't figure out is why the Program State sometimes blinks red. I don't see where I get into an infinite loop.

Current.theta is an unsigned int, and deltat is incremented every 25ms, so generally like 1 or 2. I'm going to try playing around with the order of operations, see if i can get it to work. What if instead of multipying by .08, I divided by 1/.08? would that still force the pic to use floating point calculations?

[Mark McLeod]

Originally Posted by Meandmyself

Current.theta is an unsigned int, and deltat is incremented every 25ms, so generally like 1 or 2. I'm going to try playing around with the order of operations, see if i can get it to work. What if instead of multipying by .08, I divided by 1/.08? would that still force the pic to use floating point calculations?

To stay away from all floating point (and maintain accuracy) do all your multiplication first followed by your divisions.
e.g.,

current.theta += (unsigned long) ((gyroin + gyroprev - 1023) * deltat * 8 / 100) + 2000;

[Meandmyself]

Originally Posted by Mark McLeod

current.theta += (unsigned long) ((gyroin + gyroprev - 1023) * deltat * 8 / 100) + 2000;

OK, so if Current.theta is an unsigned int, and I'm setting it equal to an unsigned long, what bits will I lose in the process? the most significant 8?
for example, what if I had this:

unsigned long longvar = 0xFAAABBBB;
unsigned int shortvar = 0;
shortvar = longvar;

shortvar would be 0xBBBB, right?

and a second question about that, am I getting an overflow error because the pic does math on an int level, and when an operation goes higher than an int I get an overflow error?

Thanks for all your help so far.

[deltacoder1020]

Originally Posted by The Lucas

just put:

extern char counter;

in your header file (user_routines.h). This will make counter a global varable that stays in memory

never put the keyword "extern" in a header file - the whole point of extern is that it points to a variable declared in another file. If you put the "extern"-ed variable declaration in the header file, you'll either have two definitions of the variable, or no definition without "extern" (you always have to have one without extern).

just put "extern" variable declarations at the beginning of an individual file.

[The Lucas]

Originally Posted by deltacoder1020

never put the keyword "extern" in a header file - the whole point of extern is that it points to a variable declared in another file. If you put the "extern"-ed variable declaration in the header file, you'll either have two definitions of the variable, or no definition without "extern" (you always have to have one without extern).

just put "extern" variable declarations at the beginning of an individual file.

He already declared counter in user_routines.c. If he puts an "extern" declaration in the header file, the variable will become static (extern is a type of statically declared variable), and able to be referenced by any file that includes "user_routines.h" (including user_routines.c). This is the way I typically declare a global var since my team has 10 programmers (6 students and 4 mentors) and every student has thier own .c file to work on.

Back on topic:

unsigned long longvar = 0xFAAABBBB;
unsigned int shortvar = 0;
shortvar = longvar;

You will get an overflow error with this code. You need to right shift out the 16 least significant bits of longvar and assign shortvar to the 16 most significant bits as shown here:

shortvar = (unsigned int)(longvar >> 16);

[Gene F]

Originally Posted by Meandmyself

the wierdest thing is happening. When I do this;

  /*way up at the beginning of the file...*/
  char counter = 0;

  /*in process_data_from_master_uP*/
gyroin = get_analog_value(rc_ana_in_01);
if (counter > 40) {
     printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));
     counter=0;
}

counter++;

printf prints out nothing. But this:

printf("%d, %d \n",gyroin,get_analog_value(rc_ana_in_01));

works fine. What's going on here?

BTW, this is all happening in the context of a larger problem that is I can't get the Gyro from last year to send values to the Edubot. When it does print, it says 0,0 no matter what.

It also has never printed the initialization message in user_initialization(). What's up with that?

Have you been running your code in the simulator on the PC? If you forget to clear the constant that lets you run on the PC simulator then you get flakey printf results. Check under the project properties for the compiler for the constant. The reason it works flakey is that with that constant set the code doesn't wait for the last character to get sent before sending the next.

Hope this helps!

[Mark McLeod]

Originally Posted by Meandmyself

OK, so if Current.theta is an unsigned int, and I'm setting it equal to an unsigned long, what bits will I lose in the process? the most significant 8?
for example, what if I had this:

 
unsigned long longvar = 0xFAAABBBB;
unsigned int shortvar = 0;
shortvar = longvar;

shortvar would be 0xBBBB, right?

and a second question about that, am I getting an overflow error because the pic does math on an int level, and when an operation goes higher than an int I get an overflow error?

Thanks for all your help so far.

Yes, you'd get 0xBBBB.
Always use a type that will hold your largest possible final value.
In this case you could shift right 16 bits.

The PIC evaluates an expression based on the largest type variable used in the expression. You can add an explicit type, e.g., (long), to force the PIC to use a long for all calculations.

[edit] You can also force the C compiler to use at least (int) for all calculations rather than defaulting to the types of the variables used in the expression. In MPLAB under Project -> Build Options... -> MPLAB C18 tab add the compiler option -Oi+

[Meandmyself]

Originally Posted by Mark McLeod

Yes, you'd get 0xBBBB.
Always use a type that will hold your largest possible final value.
In this case you could shift right 16 bits.

The PIC evaluates an expression based on the largest type variable used in the expression. You can add an explicit type, e.g., (long), to force the PIC to use a long for all calculations.

Thanks! your suggestion worked. Now the robot's printing out the right values. Now to get the motors to turn...