1. Literal Strings Consume RAM, 2. also const variables?

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

Hi,
1. I'm trying to debug someone else's app, and I noticed a big increase in usage in my Data section: I have added literal strings such as:
sputs("MHWWrite\r\n");

E.g., I get:
Program: 9692 bytes (59.2% Full)
(.text + .data + .bootloader)
Data: 983 bytes (96.0% Full)
(.data + .bss + .noinit)

When I add 3 characters, say, to the literal, both the .text & .data grow:

Program: 9694 bytes (59.2% Full) << 2 more bytes
(.text + .data + .bootloader)
Data: 985 bytes (96.2% Full) << 2 more bytes
(.data + .bss + .noinit)

There doesn't seem to be an option for AVR like the Xtensa CPU option -mtext-section-literals.

2. Also const variables seem to be linked into .data:

Help for an AVR newby, please?
Alf

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

See the thread in the tutorials forum dealing with the PROGMEM attribute.

Regards,
Steve A.

The Board helps those that help themselves.

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

Koshchi,
:oops: Oops, yes, just reading it when your post came in, and left this question on that post: Because of the separate addressing/usage of .text and .data, does this fall into the "too hard" basket to get the compiler/linker to resolve this, i.e. "const" means "Use .text & get the compiler+linker to work out what is required"? (Aren't computers supposed to free us from this tedium? :?: )
Thanks from Sunny Australia,
Alf

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

Quote:
Because of the separate addressing/usage of .text and .data, does this fall into the "too hard" basket to get the compiler/linker to resolve this

No, it falls into "C isn't designed for this type of architecture" basket.

Regards,
Steve A.

The Board helps those that help themselves.

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

The problem is, when you pass a string literal as an argument to a function, the function only receives a pointer to the first character in the string.

There is no distinction between a pointer which points to an address in SRAM, versus a pointer which points to an address in Flash -- it all just boils down to a number between 0 and 65535. However, different assembly instructions need to be generated to read data stored in Flash versus reading data in SRAM.

The function itself has no intrinsic way of knowing which memory space any given pointer it's passed is referring to, so it defaults to assuming that all pointers point to SRAM.

The header provides utilities for explicitly locating variables in Flash as required, and for interpreting pointers as though they pointed to Flash, in the specific cases where the programmer knows that's what is really required.