Re: Re: Quick Question
 

Unless the PIC C compiler is really stange and unlike all others, short int is the same as int is the same as shortthe only thing smaller is char (-128 to 127) and unsigned char (0 to 255).

Yes, both the int and short int types are 16 bit. I ran them through sizeof() to confirm it as well.

I know that int is in fact a 32-bit variable on some systems/compilers, although apparantly not on the PIC.

Re: Re: Re: Quick Question
 

I'm not sure what you mean here. On most 32 bit systems (meaning almost all desktops and a large percentage of embedded systems), the compiler will use a 32 bit value for int and a 16 bit value for short int.

The reason that int on the PIC is 16 bits is because it's only a 16 bit system, so it doesn't natively deal with a 32 bit value.

In C++ (and I assume C as well), variable types are defined as follows:

a) a short is at LEAST 16-bits
b) a long is at LEAST 32-bits
c) an int is no smaller than a short and no bigger than a long

By convention, ints are the same number of bits as the processor you are working with (which is 16 in this case), but that's not a strict requirement.

Here is the sizes of all the basic types (If i've forgotten any let me know)

char : 1 byte
short : 2 bytes (this type is the same as short int)
int : 2 bytes
long : 4 bytes (this type is the same as long int)
float : 4 bytes
double : 4 bytes
long double : 4 bytes

These values are from sizeof() so this is the way things are.

Use typedefs
 

The size of variable types (e.g. int, char, short int, long, etc) can vary for a lot of reasons. It's typically good embedded coding practice to typedef descriptive names for variable types, so type ambiguity is eliminated.

To do this, write a quick program that uses sizeof() to determine the size of all of the built in variable types. Then, use this information to create a file called "type.h" and include it in your code. type.h should look as follows:

/* type.h -- specifies meaningful type definitions */

#ifndef _TYPE_H_
#define _TYPE_H_
/* the above lines guarantee the file isn't included more than once */

typedef unsigned char uint8;
typedef signed char sint8;
typedef unsigned short uint16;
typedef signed short sint16;
typedef unsigned long uint32;
typedef signed long sint32;

/* etc. with whatever types you want to use */


/* end the #ifndef directive */
#endif

/* end of type.h */


Of course, in the above code, you need to use your results from your short "sizeof" program.

After including type.h in your program, NEVER AGAIN use the standard types (i.e. int, short, etc.) Instead, declare everything using your made-up types, so you (and others) know exactly what variable sizes you're using. For example, look at the following code:

int FilterInput; /* from looking at this, no one has any idea how big FilterInput is depending on the micro/compiler combo it could be 16-bit or 32-bit */

sint16 FilterInput; /* everyone (including the programmer) knows exactly that this is a signed 16 bit integer */


The main point is, if you set up your typedefs properly, your code is much more likely to do what you intend it to do. It also has the added benefit that it is more readable others.

-Chris

on the gyro - we used the FIRST yaw rate sensor last year for two functions

one was to close the loop on steering. If you use one joystick, then its very easy to compare the X axis input to the yaw rate of the gyro, and see how fast the bot is turning compared to how fast the driver is commanding it to turn

and close the loop on the difference. This worked extreemly well - esp if you have a bot that is hard to steer - it turns the steering into a servo function

it was also very useful for going up and down the ramp - if the driver is commanding the bot to go straight up the ramp, the yaw rate sensor can detect if its turning to one side (due to the slope of the ramp) and correct automatically. It worked like a dream.

the second function we used it for was compass heading. this is very easy to do - start out with a 16 bit variable, and add the yaw rate output to it on each loop, and subtract 127 to normalize the zero point.

you end up with a 16 bit number that is linear proportional to how many degrees you have turned left or right - dont even bother to try to make it look like 360° by dividing it, just use whatever units it comes out to be. 45° might be 4000 counts on the variable - this is easy to detemine with a little testing

as for the 70°/S rate - thats actually turning pretty quick if you are driving - there are few times when you would need to turn faster. In auton mode, if you wanted to turn 270° that would be slow - but we started out backwards and did a V turn, only needing to rotate 45° - and we were able to hit the center of the wall in about 3 seconds, very consistantly.

And if your driver really wants to turn faster than the yaw rate senosor allows (while the loop is closed) you can always program the top button on the joystick to open the loop.

Random Dude, thank you. Exactly what i was trying to hit on. When you declare just it, the compiler sees it a a short int unless you declare it as a long or long in in which case it is an int, but just holds a greater range of values. Or at least thats what Deitel & Deitel C and C++ books say along with my C for Dummies:D.

Anthony,
This is not correct. It happens to be true on the PIC C compiler. It is not true on all compilers.

I haven't been keeping up with this whole discussion, so, if this is posted earlier in the thread, my bad.

However, the whole issue of data types and sizes in the PIC 18 series can be found in the user's manual for the compiler.

This manual is located in the compiler DOC directory. The compiler should be located at:
C:\mcc18 (or something close to that).

I was actually looking for the #pragma information (which is compiler specific) and found that plus more.

opps
 

sorry about that then. I've yet ot run into a compiler that is designed in such a way, but thats probably because i stick really to only 2 compilers. But to make it clear for myself, in is always going t be short int (2 bytes) or long int(4 bytes), never inbetween(3 bytes?), right? Or can it be?

Actually, I just looked in the MPLAB-C18-USERS-GUIDE.pdf , and on page 13, (Section 2.1.1) there is the following

There is also a nice table there that gives the sizes and ranges for all data types supported by the C18 compliler. These match my previous numbers, with the addition of the "short long" type.

ohhh unique variables=fun
thanks for the head up

Re: opps
 

It can definately be in between on some systems. Take, for instance, a 64-bit processor. A long could be defined as 64-bits, a short as 16, and an int as 32. In general, variables will be an even number of bytes just because most processors access memory the most efficiently that way. However, as demonstrated by the short long int example earlier, this is not a strict requirement.

Moral of the story: any time you start using a new compiler or platform, run a simple sizeof program like the one Dave Flowerday posted. It's really the only way to know for sure what sizes each of the types are.