 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Remco
Joined: 12 May 2015
Posts: 14
|
| Bigger size structure than actually declared |
 Posted: Fri Jul 31, 2015 2:02 am |
 |
|
Goodday, it's me again.
Today I have a question about how CCS handles structures. Because of a previous post I switched to variables inside a structure. The program works fine with it. The next ting I did with it was declaring a pointer to it so that I can read byte for byte the content to write to an external EEPROM. The code I use for it is perfect. It works as it must and is double tested. But his is not the question. It's actually about the size CCS declares for the RAM. for example I have the following structure:
| Code: | #define NUMBEROFTEMPERATURES 2
STRUCT temp_struct
{
//Values that will be stored on the EEPROM
UNSIGNED int1 ON_OFF; //Select if temperature controller must be on (1) or off(0)
signed int16 SETPOINT; //33.0
signed int16 USER_CORRECTION; //is in C, set by user if nessacerry
signed int16 INTERNAL_SETPOINT; //33.0C
float32 DEFAULT_CORRETION; //is in V, generated through software
float32 SLOPE; //generated through software
//Value WILL NOT be stored on the EEPROM
UNSIGNED int8 AN_INPUT; //Analog input for the two K-couples
float32 INTERNAL_VALUE;
float32 VALUE; //Measured temperature
signed int16 MAX; //Max temperature 50.0 C
signed int16 MIN; //Min temperature 0.0 C
};
STRUCT temp_struct Temperature[NUMBEROFTEMPERATURES] = {
{FALSE,330,0,330,0.5873,0.0,10,0,0,500,0}, //0 = Temperature 1
{FALSE,330,0,330,0.5873,0.0806,11,0,0,500,0}}; //1 = Temperature 2 |
In the Symbols file this structure is allocated at 96C-9A7. This results in 60 bytes location, but the declared function is only 56 bytes big. So somewhere CCS has added 4 extra bytes. And when I changed it to only 1 it had still 2 extra bytes, and changed to 3 it has 6 extra bytes. This is with a few other structures to. But I have alse one structure that has only I bytes extra:
| Code: | STRUCT pH_struct
{
//Values that will be stored on the EEPROM
UNSIGNED int1 ON_OFF;
UNSIGNED int1 SYMMETRY;
UNSIGNED int8 SETPOINT; //7.0pH
signed int8 USER_CORRECTION; //0.0pH
float32 SLOPE;
float32 DEFAULT_CORRETION;
//Value WILL NOT be stored on the EEPROM
UNSIGNED int8 AN_INPUT;
float32 VALUE;
UNSIGNED int8 MAX; //12.0pH
UNSIGNED int8 MIN; //2.0pH
};
STRUCT pH_struct pH[NUMBEROFPHS] = {
{FALSE,FALSE,70,0,-0.1807,3.8528,13,7.0,120,20}}; //0 = pH1 |
For this file 20 bytes is allocted and the actual size is 19.
The only thing I could find in the datasheet of the compiler is:
Field Allocation
- Fields are allocated in the order they appear.
- The low bits of a byte are filled first.
- Fields 16 bits and up are aligned to a even byte boundary. Some Bits may by unused.
- No Field will span from an odd byte to an even byte unless the field width is a multiple of 16 bits.
But it doesn't make sense because in some cases it then must be more bytes added or otherwise. And if I remember it correctly there wont be any pointers added under water or added something else. I have a work around for it but I doesn't make it any better or simpler to understand when someone else must use it.
Did I miss something or didn't I get the memo? If you can help, it would be a great help for me. I use it for a dsPIC30f6014A with Version 5.042 for the compiler.
Greeting,
Remco |
|
 |
Remco
Joined: 12 May 2015
Posts: 14
|
|
| Posted: Fri Jul 31, 2015 2:34 am |
|
|
I just tried and it explained it.
What they say in the datasheet is actually true. Only they also look if there is an another int8 previous, if so they combined the two. They just don't add an extra byte for each int8. I find it silly but at least is something better to deal with. |
|
|
Remco
Joined: 12 May 2015
Posts: 14
|
|
| Posted: Fri Jul 31, 2015 5:33 am |
|
|
| But still after I find the solution, it behaves strange. Sometimes it will add those extra bytes but sometimes it will not. Very strange |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19369
|
|
| Posted: Fri Jul 31, 2015 7:26 am |
|
|
You don't tell us what processor?.
It sounds like word alignment.
On chips like the PIC24/3o etc., int16 variables (and int32 or float), _must_ align on word boundaries.
So if you declare (for example), a structure with an int8, followed by an int16, followed by another int8, and another int16, this will have to use 8 bytes, since there has to be a padding byte inserted to align the int16's onto the word boundaries. If instead you layout as int8, int8 int16, int16, it'll only use 6 bytes. |
|
|
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
