View previous topic :: View next topic |
Author |
Message |
akohlsmith
Joined: 25 Apr 2012 Posts: 26
|
PCD manual error? |
Posted: Fri Oct 04, 2013 10:47 am |
|
|
I'm looking at the September 2013 PCD manual. It states that the standard C type 'int' is mapped to 'int8' for PCD.
I have "int ticks" in my code and the compiler is most definitely using 16 bits for the variable, both for storage allocation and for use. The target is PIC24F32KA304, and I am using #device ANSI as well.
Is this a manual error, a compiler option that the manual does not describe or something else? |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Oct 04, 2013 11:27 am |
|
|
It's a manual error. In PCD, int = signed int16. |
|
|
akohlsmith
Joined: 25 Apr 2012 Posts: 26
|
|
Posted: Fri Oct 04, 2013 11:30 am |
|
|
Excellent, thank you for the verification. |
|
|
SteveW
Joined: 27 Sep 2005 Posts: 25
|
|
Posted: Fri Oct 04, 2013 11:33 am |
|
|
I have gotten in trouble so many times with this issue with the CCS compilers that I now always clearly define all variables (i.e., "unsigned int16" or "signed int8", never simply "int"). |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1907
|
|
Posted: Fri Oct 04, 2013 2:19 pm |
|
|
Same here - now. I've only been involved with PCD for about a year but prior to that, pretty much exclusively PCH. Took code written & proven good from an 18 series PIC and migrated the same code to a dsPIC. Huge disaster. Boiled down to ints being UNsigned by default on PCH and changing to signed by default on PCD.
Now I explicitly say whether it's signed or not. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19504
|
|
Posted: Fri Oct 04, 2013 2:42 pm |
|
|
Yes.
There are two different approaches that work.
1) Use the explicit names. Even better than the defaults, load the file 'stdint.h'.
2) Use your own explicit #type statement.
The latter is particularly useful if moving PIC16/18 code to a later chip, but if you define the sizes to be 'unusual', can lead to problems with the library code.
Best Wishes |
|
|
|