Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
sjackson
PostPosted: Aug 07, 2009 - 10:28 PM
Rookie


Joined: Apr 11, 2007
Posts: 38


I was asked recently what the total RAM and Flash usage of one of my applications was. I figured an easy way to do this was to rebuild the project and look at what avr-size dumps out. I never caught on before but it seems that .data is used to calculate both the "Program" and the "Data" sizes. Further it appears that Program=Flash and Data=RAM. How can .data reside in both places at once? I see from some online WinAVR documentation that .data contains static variables and that one can change the location of the .data section. However it still seems it needs to reside completely in ROM or in RAM.

Am I just misunderstanding something here? Is the best strategy to look directly at the output of
Code:
avr-size -A -x Filename.elf
and calculate memory usage myself based on what address each section resides in?

Thanks in advance.
 
 View user's profile Send private message  
Reply with quote Back to top
sternst
PostPosted: Aug 07, 2009 - 11:26 PM
Raving lunatic


Joined: Jul 23, 2001
Posts: 2728
Location: Osnabrueck, Germany

.data is the section where your initialized variables are in. The variable itself lives in RAM, but the value for the initialization must also be stored somewhere.
Code:
unsigned char var = 1;
This consumes one byte of RAM for the variable and one byte of Flash for the initial value. In fact there is kind of a .data-mirror in Flash that is copied to RAM on the program startup to initialize the variables.

_________________
Stefan Ernst
 
 View user's profile Send private message  
Reply with quote Back to top
stu_san
PostPosted: Aug 08, 2009 - 10:54 PM
Raving lunatic


Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA

To continue, .bss is the area for unitialized variables go. the avr-libc library automatically sets these to 0 during the initialization sequence.

One other thing you need to think about: "automatic" variables and stack usage. After all, if you do:
Code:
function foo (int bar, char* gort)
{
   char flurb[128];
. . .
}
Calling foo() will push 2 bytes for bar, 2 bytes for gort, 128 bytes for flurb, 2 bytes for the return address, and a variable number of bytes to push the current values of the CPU registers on entry.

There was a simple-minded stack calculator pointed at in a thread a week or so ago -- I don't have the pointer here at home, but a forum search may find it.

Stu

Edit: I found the thread. The program can be found here. I did a quick translation of the readme from German to English, which I posted here

_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!
 
 View user's profile Send private message  
Reply with quote Back to top
clawson
PostPosted: Aug 09, 2009 - 05:05 PM
10k+ Postman


Joined: Jul 18, 2005
Posts: 69288
Location: (using avr-gcc in) Finchingfield, Essex, England

Quote:

Calling foo() will push 2 bytes for bar, 2 bytes for gort,

Sorry to be a pedant but the parms to the function will not be passed on the stack (that only happens when the registers run out). 'bar' will be in R25:R24 and 'gort' in R23:R22

_________________
 
 View user's profile Send private message  
Reply with quote Back to top
stu_san
PostPosted: Aug 10, 2009 - 03:27 PM
Raving lunatic


Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA

clawson wrote:
Quote:

Calling foo() will push 2 bytes for bar, 2 bytes for gort,

Sorry to be a pedant but the parms to the function will not be passed on the stack (that only happens when the registers run out). 'bar' will be in R25:R24 and 'gort' in R23:R22
Embarassed Duh! You're right! Sorry, had a massive brain fart there.

There will be 128 bytes allocated on the stack (after the return address, but I'm not sure in what relation to the register saving) for the local buffer. Unless, of course, you don't use the buffer, in which case the optimizer may drop it out.

Serves me right for tossing this one in "off the cuff".

Stu

_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits