Data segment > 100%?

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is it a problem that I need to fix that the gcc compiler is reporting I'm at 130% of the data segment?

If so how do I fix it?

I'm using GCC (via winavr) in AVR Studio.

I hope this is an appropriate forum for this. I've searched for an hour but can't find anything that explains it. I hope someone can please point me in the right direction.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Is it a problem that I need to fix that the gcc compiler is reporting I'm at 130% of the data segment?

Yes, definitely.

How you fix it depends on what is using the memory. Without seeing your code it is hard to be sure, but one of the most common things that you can do is make sure that all of your constant strings are in flash, not ram (through the use of PROGMEM).

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, that sounds like just what I need to do.

I do have an array of 400 bytes. This is on an ATtiny85V. I'll look into PROGMEM. Hopefully at the same time I'll find a solution to my other issue: An efficient way to define a large static array of bytes. I was searching for how to define array literals in C, and was surprised to find pages saying C++ does not support them. I'm using C, which I assume is the same in this way.

Thanks again!
Tim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, it looks like I'm on my way. I found the progmem tuturial by abcminiuser and an example of array literals. Thanks again!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

timwhunt wrote:
surprised to find pages saying C++ does not support them.
C++ does not support the use of literal arrays as initialisers for non-trivial objects.
Quote:
I'm using C, which I assume is the same in this way.
No, it's not really. The C++ restriction arises out of the strictness with which C++ approaches object construction and initialisation. C does not have the same rules (or facilities) as C++ in this respect.

In C++ you CAN have initialised static const arrays of plain data types, and if you're contemplating putting them in PROGMEM then "static const"-ness may well be appropriate.

#include 
static const unsigned char PROGMEM a[] = {1, 2, 3, 4}; // OK in C++ or C

With avr-gcc's implementation of C++ you can even use static const PROGMEM arrays like this as member variables of classes.

Christopher Hicks
==

Last Edited: Mon. Oct 26, 2009 - 02:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot for clarifying Christopher!

I worked it out using code very much like your sample. Now I have tons of room for my data.

Another surprise was what a difference just including some float calculations made. As soon as I added a few lines dealing with floats, my code and data segments ballooned. I switched to fixed point math and got back a lot of space.

In case anyone's interested, I'm making a little controller for red, green, blue, and white LEDs for inside a jack-o-lantern for Halloween. The data I'm now storing in flash memory is the sequence of levels; 16 levels available for each LED.

Thanks again for the help!
Tim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As soon as I added a few lines dealing with floats, my code and data segments ballooned.

Linking with libgcc.a or libm.a ? One costs about 3-4K, the other <1K

(but avoiding floats is a better solution anyway)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Linking with libgcc.a or libm.a ? One costs about 3-4K, the other <1K

I didn't explicitly link with either by adding a new include statement. Maybe that was a mistake. It seemed strange that the code ballooned anyway - I didn't think working with floats would take that many instructions. I suspected the compiler/linker might have automatically added a lib. But I switched to fixed point before investigating. I thought I'd probably end up using fixed point, but tried floats first because it was trivial to code, would be more flexible, and it had a chance of working.

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The key thing (if fp/math.h is to be used) is to ensure the linker gets a "-lm" (which means "(-l)ink with lib(m).a") otherwise the linker will fall back to using some 80386 optimised code out of libgcc.a which is very bad news (and sometimes just plain wrong!)

Cliff

Last Edited: Mon. Oct 26, 2009 - 05:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow that sounds like a bad gotcha.

I'm going to repeat that to myself 10 times hoping some faint neuron will fire and I'll remember enough to save myself when I do need to use floats.

Thanks again!
Tim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you use a Makefile created by Mfile then by default it handles the libm.a situation but if you let AVR Studio automatically create your Makefile for you then sadly (despite being told) Atmel have not managed to arrange for the avr-gcc plugin to default to linking with libm.a - which is a shame as it's Studio that beginners tend to use.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks again.

I just took the bait and clicked on the footer of your last message to read more FAQs. I'm a little embarassed to see some of what's been discussed here covered in the FAQs. But I'm glad to have read them (again I think), and to be reminded to check them in the future.