CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Bigger size structure than actually declared

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Remco



Joined: 12 May 2015
Posts: 14

View user's profile Send private message

Bigger size structure than actually declared
PostPosted: Fri Jul 31, 2015 2:02 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Jul 31, 2015 2:34 am     Reply with quote

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

View user's profile Send private message

PostPosted: Fri Jul 31, 2015 5:33 am     Reply with quote

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: 19545

View user's profile Send private message

PostPosted: Fri Jul 31, 2015 7:26 am     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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