MEMORY SRAM COMPILER

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
Hello , I have a question . I'm using AVR6 and micro ATXMEGA64u3 . Everything works fine , and I have done several projects . 
Now a problem, the SRAM used for 83 % . If I put a few bytes to use in more me freezes the program execution on the targhet .
so I ask you :
1 ) why can not I use 100% of the sram ?
2 ) the stack is placed by AVR6 ?
3 ) give me a solution ?

P.S. I used several arrays and pointers to vectors and function

 

 

 

 

 

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

stack is placed in RAM aswell.

 

But a more commen problem is that constant strings like this :

 

    ptr=("  Copyright       ");

 

will under normal C be copied to RAM so if you things like that could be your problem.   

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

Yes, i use many of this

//const char msg34_ing[] = {"  WAIT  "};    // 34
//const char msg35_ing[] = {" REMOTE "};    // 35
//const char msg36_ing[] = {"PRESS OK"};    // 36

//const char * msg_ing[] = {msg0_ing,msg1_ing,msg2_ing,msg3_ing,msg4_ing,msg5_ing,msg6_ing,msg7_ing,msg8_ing,msg9_ing,msg10_ing,
                        //msg11_ing,msg12..........

 

but the memory is not full. I have 13% empty

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

The memory usage reported as 83% is only statically allocated data. The compiler knows little or nothing about how much additional RAM the stack and heap will use at run time. Also, there is no actual check at runtime if it would happen that usage goes over 100%. The stack simply grows into the heap, and eventually if it keeps growing its top address will "wrap back to zero" and it will overwrite statically allocated data.

 

The canonical figure is the first on on this web page. .bss+.data is statically allocated data. Then the stack and heap takes the rest growing towards each other from opposite wends. Assuming you do not allocate on the heap, then the stack can grow all the way up to the top of RAM. If it grows anu further, the stack pointer will actually wrap back to address zero and the stack starts overwriting .bss/.data.

 

The opposite scenario is of-course also possible: The stack has already wrapped and grown into .data/.bss. Now the code writes to a variable in e.g. .data, but doing so it will effectively thrash some of the stack (a part of the stack that is where it should not be, but anyway...). Let's assume that it is a return address that gets thrashed. Then the code actually does the RET. Now you return to an unknown place in arbitrary code, and you have a runaway program.

 

Advice:

One way to  to reduce the size of .data - thereby leaving more RAM for the stack: No literal strings in code. Investigate the __flash attribute. Load strings to RAM only when they are actually needed.

 

One way to lessen the growth of the stack: Remove parameters passed, possibly through several function calls, and keep them in a global statically allocated variable. Ugly perhaps, but if it is the last resort...

 

For other advice we would need to see the project.

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

OK tanks,

 

now reduce the space in ram moving the text in flash, with PROGMEM.

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

There is no "ATXMEGA64u3".

 

Assuming its and ATXmega64A3 then that has 4 KB of RAM, and then 17% left for the run time is something like just under 700 bytes for the stack and heap. Depending on yor code that might be more than enough, or way to little.

 

1) Do you have many levels of calls with a lot of and/or large parameters?

 

2) Do you allocate dynamically with malloc() (or new-operator if you're coding in C++)? Are you then free()ing/deleting in the reverse order of allocation? (If not, then your heap will be sparsely defragmented. No, there is no garbage collector in C/C++... [1])

 

3) Just to make sure: You're not doing recursive calls, are you?

 


 

[1] Well, not in standard C/C++. Well, not in C anyway. And not in C++, yet, anyway. And even if there was, it would likely not be usable in a tool chain for small microcontrollers.

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

you should use a newer compiler where you can use __flash !

That make your code "cleaner".

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

JohanEkdahl wrote:
1) Do you have many levels of calls with a lot of and/or large parameters?

and/or with a lot of and/or large automatic variables?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find it very difficult to accurately predict the amount of memory a project is going to take ahead of time.

 

It is often wise to start your project on a much larger device than you expect to need.

Then you don't end u in this situation, where your project isn't completed and you are out of memory.

 

If, when you finish a project you find you could use a smaller micro then you can decide if it is worth porting the project to the smaller device.

For a large production run it may well be worth it.

If you are only building one / several, it may not be worth the time and effort to do so.

 

Note that porting between Xmega chips, (within a family), is typically easier than porting code amongst several of the other micros

 

JC