Memory Usage Info After Linking

17 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I'm looking for a way of knowing the RAM usage (%) of a program. I'm using libraries and I just solved a problem related to memory usage. That is, it goes wrong when a static (global) array is too big. However, the linker never gave any error nor warning.

Is there a way of knowing the maximum memory usage of a program after linking, you know, the worst case when an ISR that uses local variables is executed while the stack is already used a lot and so on...

Thank you!

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

avr-size

If you use either Studio+WinAVR or Mfile/Makefile+WinAVR you should be seeing something like this at the end of your build:

AVR Memory Usage
----------------
Device: atmega16

Program:    7376 bytes (45.0% Full)
(.text + .data + .bootloader)

Data:         81 bytes (7.9% Full)
(.data + .bss + .noinit)

EEPROM:       63 bytes (12.3% Full)
(.eeprom)

(that output is using the -C option on avr-size but this requires a patch that is normally only evident in the WinAVR build of avr-size and in other environments you may have to make do with -A or -B)

 

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

If you use the Studio4 default makefile, it calls avr-size. This will give an indication of your RAM usage.

As far as I know avr-gcc does not report on excessive stack usage from inappropriate recursion.

David.

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

Previous threads of mine and also a thread in the tutorial forum present an idea where you add a .init3 routine that floods SRAM with a recognizable value. You then run the code for a while then stop it in the debugger and examine the RAM. As long as there are still some of the recognizable bytes between the end of .bss and the low water mark of SP then you are probably OK with run time stack frame usage.

Cliff

 

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

quick question related to the avr memory usage. I'm not sure what 'Data' is. The program that i wrote occupies 71.9% in my atmega16, it seems to be working fine. Should i worry about the Data 132.8% Full?

Quote:

AVR Memory Usage
----------------
Device: atmega16

Program: 11784 bytes (71.9% Full)
(.text + .data + .bootloader)

Data: 1360 bytes (132.8% Full)
(.data + .bss + .noinit)

Thank you,

Eric

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

Quote:
Should i worry about the Data 132.8% Full?
Yes, very. Data is your SRAM usage, and it is only the amount that the compiler knows at compile time. You also need room for things created at runtime (particularly stack usage).

Regards,
Steve A.

The Board helps those that help themselves.

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

Eric,

You need to get Data down to about 75% or less to be "safe". The "unused" 25% is what will actually be used on the stack for return addresses and local variables.

Often the thing wasting RAM are constant strings and tables of data which, if you do nothing to prevent it, will be copied to RAM when the program starts. To prevent it you keep them in code flash using PROGMEM which is explained in an article in the Tutorial Forum.

Cliff

 

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

Thank you Steve and Cliff, i have upgraded the chip to an atmega64. One more quick question, i have read in some thread that avr studio can migrate a code from, say, an atmega16 to an atmega64. But i can't find that thread, and i am not sure how to do it. Could you please tell me how to?
thanks!
- Eric

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

In most cases all that is required within a family is to recompile the code with the new processor set. If there are errors about unknown registers you fix those, obviously, as you go. If you don't have the source... well that's a different matter.

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

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

oh, ok, thanks Martin. i thought there was a way that avr studio would update the registers automatically when changing the microcontroller...

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

Quote:

i thought there was a way that avr studio would update the registers automatically when changing the microcontroller

Studio is about as simplistic as it could possibly ever get when it comes to IDEs. Be thankful it can even edit/build programs but don't expect anything more from it.

To be honest I've never heard of a "porting assitant" as you describe here.

It's true that going up and down a family line: 48<->88<->168<->328 or 8535<->16<->32 is relatively painless (though even a 48 is quite different from 88/168/328). But going across from a 16 to a 168 is quite a bit more complex and can only really be achieved by close studying of the respective datsheets.

 

Pages