When using avr studio, what does it mean when data is <100% full on programming?

[corrado33]

I'm using an AtTiny4313 for a project of mine, and when I program it with my very simple program, in the build window, it says

Data: 103.1% Full.  Is that bad?  What will happen?  What affects that?

My program is not full, just the data?  Too many variables?  

[mstacho]

Yeah, it means you're using too much RAM, so too many variables.  It should...fail weirdly and unpredictably, since RAM won't always be set up the same way (hence *random*).

The Tiny has something like 100B of RAM, right?  So it looks like you're only a few Bytes over the limit.  Can you change anything to #define statements?

MIKE

[corrado33]

Probably could, I was trying to get the program to work and not really thinking about being efficient.  I'll figure it out.  

EDIT:  HMMMM, I keep deleting variables and that number isn't going down.......

[corrado33]

I know, double post again.

I found out what it is.

Here's some pseudocode.

Code: [Select]


int main()
{
int count;
while(count < timeinMS)
{
stuff stuff;
count = count +1;
}
}


That "count = count + 1" accounts for 256 bytes of data memory.  Whether AVRStudio is being smart and eliminating the infinite loop when I delete the line or not, I don't know, but something is going on there.  It's just a simple integer, it shouldn't take that much space.  When I comment out that line, I use 8 bytes of data space.... what the heck?

[mstacho]

yeah, that is weird.  An integer shouldn't be anywhere near 256B...hell, doubles aren't even that big...this might sound absurd, but try this:

int tmp = count;

while loop starts

tmp = count + 1;
count = tmp;

stuff;
end loop

that might stop the self reference of count = count + 1, although I don't possibly see why it was taking up so much space!

MIKE

[mstacho]

Alternately, try this:

int count = -1;
while (count++ < timeInMS)
{
    DO_STUFF;
}

That MIGHT elliminate the double-reference to count...but if I'm not mistaken, count = count + 1 shouldn't take place in RAM anyway, although I might be giving the ATTiny more credit than it needs :-P

MIKE

[Webbot]

Since 'count' is a local variable (ie defined within a function) then it should not take up ANY permanent RAM at compile time. At runtime it will require 2 bytes from the stack - ie the memory is allocated during the running of the function and then disposed when the function exits.

This kind of stuff isn't reported by AVRStudio when listing code and data sizes as it has no idea what the total requirement may be as it will depend on what functions call what other functions, in what order, etc etc. It just can't calculate it.

I suggest you look at the .map and .lst (or .lss) files - assuming your build process is outputting them. This may help you to track down where the data space is going.

Since the 'tiny' range is just that (small amounts of everything) then you tend to need to write stuff in assembler to get the best, ie smallest, results. C plus other libraries, including my own WebbotLib, add some bloat and hence my target platforms tend to be the ATMegas.

[rbtying]

Alternately, try this:

int count = -1;
while (count++ < timeInMS)
{
    DO_STUFF;
}

That MIGHT elliminate the double-reference to count...but if I'm not mistaken, count = count + 1 shouldn't take place in RAM anyway, although I might be giving the ATTiny more credit than it needs :-P

MIKE

Your code there is quite interesting... wouldn't a pre-increment be more like what you're looking for?

Code: [Select]

while (++count < timeInMS) {
[...]
}

From what I remember, pre-incrementing in loops is slightly more efficient when processed by the compiler (jump if not zero instead of load/compare/jump) but I'm not too sure.  Plus the post-increment version executes the loop an extra time xD.

What happens if you replace int count with uint8_t count?  (That should restrict the size of count, at least)

[corrado33]

Alternately, try this:

int count = -1;
while (count++ < timeInMS)
{
    DO_STUFF;
}

That MIGHT elliminate the double-reference to count...but if I'm not mistaken, count = count + 1 shouldn't take place in RAM anyway, although I might be giving the ATTiny more credit than it needs :-P

MIKE

Your code there is quite interesting... wouldn't a pre-increment be more like what you're looking for?

Code: [Select]

while (++count < timeInMS) {
[...]
}

From what I remember, pre-incrementing in loops is slightly more efficient when processed by the compiler (jump if not zero instead of load/compare/jump) but I'm not too sure.  Plus the post-increment version executes the loop an extra time xD.

What happens if you replace int count with uint8_t count?  (That should restrict the size of count, at least)

Yes, I read through the "Effecient coding in AVR" PDF from Atmel and adjusted my code to something like this...

Code: [Select]

int main()
{
TimeinMS = ###
while(TimeinMS--)
{
stuff stuff;
}
}




It works.  I have no idea what was going on before. 

[mstacho]

Here's my guess:

count = count+1;

does the following in memory:

int tmp = count; (copy count)
tmp = count + 1; (increment count.  Yes, I'm aware I did this in two steps.  My guess is this is the machine-code version of how that line is implemented)
count = tmp; (erase existing count and put tmp in its code)
tmp = null (erase tmp)

while count++, tmp-- or whatever just calls the increment/decrement instruction without screwing with memory at all.

That's a HUGE guess, though, and it still wouldn't explain why it took up 256 times more memory than it should have :-P

Glad you fixed it, though.

MIKE

ps: I could be wrong, but I've always thought that, technically, decrement/subtraction took more instructions that increment/addition.

[KurtEck]

Personally I think the increment or decrement of an integer value is probably not the culpret here.  Yes you can run into issues if a variable is not large enough to hold the value that you are comparing to, to exit a loop.  But again this does not change how much data your program is using.

Things I would check include:
a) How much stack space is defined, or does it simply default.  Likewise do you have a heap defined...
b) What if any libraries are you linked with.  These can quickly eat up your space.

c) do you have some static tables. Things like:

Code: [Select]

static const byte GetACos[] = {   
                    255,254,252,251,250,249,247,246,245,243,242,241,240,238,237,236,234,233,232,231,229,228,227,225,
                    224,223,221,220,219,217,216,215,214,212,211,210,208,207,206,204,203,201,200,199,197,196,195,193,
...Will eat up all of your memory, but if you change the first line to look like:

Code: [Select]

static const byte GetACos[] PROGMEM = {    This will put the table into the program space instead of data space.  You then have to tell the compiler that you are accessing the table... Like:

Code: [Select]

        AngleRad4 = pgm_read_byte(&GetACos[cos4/79]);

Good Luck
Kurt

[corrado33]

Things I would check include:
a) How much stack space is defined, or does it simply default.  Likewise do you have a heap defined...
b) What if any libraries are you linked with.  These can quickly eat up your space.

c) do you have some static tables. Things like:

Code: [Select]

static const byte GetACos[] = {   
                    255,254,252,251,250,249,247,246,245,243,242,241,240,238,237,236,234,233,232,231,229,228,227,225,
                    224,223,221,220,219,217,216,215,214,212,211,210,208,207,206,204,203,201,200,199,197,196,195,193,
...

a) No idea, but I'd assume it would be much because with that line gone it was only 8b of data?
b) No libraries linked.  Only include statement was io.h
c) No static tables.  I did have a 4 postion list though.

[KurtEck]

Sorry that it did not help.

In cases like this, I then look at the map file to see what is in the data section. (With AVRstudio, check the box in the project options).  With Arduino, little more complicated...

Or I use the command line program objdump to generate the information.  On my machine I think this is located at: c:\winavr\avr\bin.  I open a command prompt, cd to the directory with my object file and type something like:
"\winavr\avr\bin\objdump -D debrat.o > foo"
I then look at the output file foo...