data memory VS program memory

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

i don't understand the difference and then i can't reduce in a program the data memory... i write in c withi avr studio winavr for atmega16 a program but wen compile i have 1025 bytes 100.1% data memory full.. what can i do for reduce the data memory????

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

You probably have several anonymous strings e.g.

printf("Hello World");    // the string is anonymous.

A feature of avr-gcc is that it copies these into SRAM. They are still anonymous. i.e. you cannot access them to either read or write.
You can force them into flash space.

printf_P(PSTR("Hello World"));    // the string is still anonymous.

Of course most other Compilers are not quite so stupid. They will place anonymous strings into flash automatically. However this sometimes creates unexpected problems.

So you have to be aware of the difference between a flash string and a SRAM string. One of the penalties of the AVR's Harvard architecture.

But at least it has not used up your valuable SRAM.

David.

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

PROGMEM tutorial in the Tutorial Forum (which is always a good place to start looking for a solution to a problem)

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

the code that make this problemi si in a project on avrfreaks, is a project for graphics lcd dog128 by dzairo...
this is a really good example and complete project and make for atmega32
i want run this project on atmega16 and i have problem for datamemory 100.7 full but i think this is for some error on code...
you can see the code on project page

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

Then reduce RAM buffers or accept the fact that you need to use an AVR with more RAM. You will never fit a quart into a pint pot.

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

To show RAM allocation:

$ avr-objdump -t -j .data foo.elf
$ avr-objdump -S -j .data foo.elf
$ avr-objdump -t -j .bss foo.elf

The .data section uses both flash and RAM for preinitialized variables, .bss for those that are initialized to zero at startup. Looking at RAM in the AVR studio debugger is another way to find strings that could be moved to flash.

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

effectively in the main there is this code

g_draw_string(10,10,"Test",1);

if i comment and compile my datamemory is 100.1%, if i delete the comment and compile the datamemory is 100.7% full... but I can not find another string or problem in the main code...

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

clawson wrote:
Then reduce RAM buffers or accept the fact that you need to use an AVR with more RAM. You will never fit a quart into a pint pot.

yes but i whant understand if there is a problem in the code, if there isn't a code problem i buy an atmega32

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

Quote:
if i comment and compile my datamemory is 100.1%, if i delete the comment and compile the datamemory is 100.7% full... but I can not find another string or problem in the main code...

Then your AVR will not be capable of running the code. Simple as that. You need to throw stuff out of the code or get a bigger AVR.

And don't get fooled into thinking that it will run OK as soon as you get under the 100 percent limit. The number presented to you is the RAM usage that can be computed at compile time. Added to that a certain amount of additional RAM will be needed at run-time. The common advice is that after building an application you want to have about 75 percent of your RAM used up. Maximum. (It varies with application though, but you will never be able to run the app with eg 95 percent of RAM used up already at compile time.)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

JohanEkdahl wrote:

Then your AVR will not be capable of running the code. Simple as that. You need to throw stuff out of the code or get a bigger AVR.

this is shure but i want to throw stuff out of the code and i try but I do not know memory very good and than i dont know very well what can i do for this.. i buy an atmega32 by internet and this take more time.. in this thime i can throw stuff out of the code for make some small test and study the memory of avr...

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

I would guess that this is an excellent example for 'worrying' about code size.

Can you scrimp and save SRAM so that you can get the data memory down to about 75-80% ?

Or do you move straight to a mega32 with 2048 bytes of SRAM ?

Once you have made the decision, you have twice the flash and twice the SRAM. You will probably fit any project that you want.

If you have to buy the AVR in the first place, there is no contest. Buy the bigger AVR. Even consider buying a mega324PA which is better and cheaper!

David.

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

You mentioned "dog128" and "dzairo". I take it, therefore, that you mean this:

https://www.avrfreaks.net/index.p...

I just downloaded and built that project:

D:\M32-DOGM128-6\default>make
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99        -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT mai
n.o -MF dep/main.o.d  -c  ../main.c
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99        -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT dog
m-core.o -MF dep/dogm-core.o.d  -c  ../dogm-core.c
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99        -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT LCD
_ST7565.o -MF dep/LCD_ST7565.o.d  -c  ../LCD_ST7565.c
../LCD_ST7565.c: In function 'LCD_Draw_Pixel':
../LCD_ST7565.c:100: warning: unused variable 'adrLaw'
../LCD_ST7565.c:100: warning: unused variable 'adrPage'
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99        -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT rpr
intf.o -MF dep/rprintf.o.d  -c  ../rprintf.c
avr-gcc  -mmcu=atmega32 -Wall -gdwarf-2 -std=gnu99        -DF_CPU=8000000UL -Os
-funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT del
ay.o -MF dep/delay.o.d  -c  ../delay.c
avr-gcc -mmcu=atmega32 -Wl,-Map=DOGM128-6.map main.o dogm-core.o LCD_ST7565.o rp
rintf.o delay.o     -o DOGM128-6.elf
avr-objcopy -O ihex -R .eeprom -R .fuse -R .lock -R .signature  DOGM128-6.elf DO
GM128-6.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section
-lma .eeprom=0 --no-change-warnings -O ihex DOGM128-6.elf DOGM128-6.eep || exit
0
avr-objdump -h -S DOGM128-6.elf > DOGM128-6.lss

AVR Memory Usage
----------------
Device: atmega32

Program:    5440 bytes (16.6% Full)
(.text + .data + .bootloader)

Data:         38 bytes (1.9% Full)
(.data + .bss + .noinit)

THIRTY EIGHT bytes of "Data" used. Where on earth is your 1000+ figure coming from?!? Have you modified the project since downloading it?

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

there is two similar project, the project on your post is for text and char not for graphics work, in this link

https://www.avrfreaks.net/index.p...

there is the second project with graphics management, like drow a crcle or line and bitmap

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

Then accept the fact that on the mega16 you can only use text for the time being until you can get the mega32 you need to support the other functions.

EDIT: I see what you mean with the other project:

AVR Memory Usage
----------------
Device: atmega32

Program:    6784 bytes (20.7% Full)
(.text + .data + .bootloader)

Data:       1031 bytes (50.3% Full)
(.data + .bss + .noinit)

As you can see, of the 1031 bytes:

D:\M32-DOGM128W-6-G\default>avr-nm --size-sort DOG128W-6.elf | grep " B "
00000001 B g_inverted
00000400 B disp_ram

1024 of them (0x400) are for a buffer called "disp_ram". I imagine it would be close to impossible for the code to work either without this or with it reduced in size. As 1024 is always going to consume the entire mega16 RAM even with no other RAAM usage present (but there always will be) this confirms that you simply cannot use this code in less than a mega32

PS Just checked the usage of disp_ram:

D:\M32-DOGM128W-6-G>grep disp_ram *.[ch]
driver_dogm128.h:// Set pixel (x,y):     disp_ram[(y >> 3) + (x << 3)] |=  (1 <<
 (y & 0x07));
driver_dogm128.h:// Clear pixel (x,y):   disp_ram[(y >> 3) + (x << 3)] &= ~(1 <<
 (y & 0x07));
driver_dogm128.h:uint8_t disp_ram[1024];
driver_dogm128.h:                       dogm_send_display_data(disp_ram[page + (
column << 3)]);
driver_dogm128.h:               disp_ram[d] = 0x00;
driver_dogm128.h:               disp_ram[d] = 0x00;
driver_dogm128.h:                       disp_ram[(y >> 3) + (x << 3)] |=  (1 <<
(y & 0x07));
driver_dogm128.h:                       disp_ram[(y >> 3) + (x << 3)] &= ~(1 <<
(y & 0x07));

Rather worryingly the author has put all the support code in a .h file - but be that as it may - the low level stuff works by set_pixel writing to the disp_ram buffer then disp_send_frame() pumping the entire frame out to the display.

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

The dogm128 library at
http://code.google.com/p/dogm128/
only stores one page of the display in the RAM (128 bytes for the dogm128).
This lib has been ported to attiny84, but there is no out of the box solution for atmega yet (which uses a different SPI hardware).

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

Quote:

which uses a different SPI hardware

But it's actually MUCH simpler than the Tiny so porting it should take about 10 minutes.

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

thank you at all for information! if i want to make an animation on display like an analog indicator for example, the atmega 32 and the dzairo code is ok? i don't have lot experience for porting by attiny to atmega but thank you for information... i can download and make some test...

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

Meanwhile, the dog-lib at
http://code.google.com/p/dogm128/
has been ported to ATMEGA and the ATMEGA SPI.

Oliver