#144299 - Programix - Wed Oct 31, 2007 8:46 am
Can I get somehow value of how much ram or vram is free?
#144300 - Mighty Max - Wed Oct 31, 2007 8:58 am
Use meminfo for the wram
vram is manually assigned. Thus you should allways know how much there is, and how much there is left in the different banks
_________________
GBAMP Multiboot
#144306 - Programix - Wed Oct 31, 2007 11:38 am
What is meminfo?? :D how to use it?
#144312 - Mighty Max - Wed Oct 31, 2007 1:37 pm
#144314 - Programix - Wed Oct 31, 2007 2:17 pm
Thanks very much!
#144339 - tepples - Wed Oct 31, 2007 7:44 pm
mallinfo doesn't appear to be in <stdlib.h> of devkitARM R20, but it's in <malloc.h>.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#144626 - conejoroy - Sun Nov 04, 2007 11:30 pm
just a question... I'm having a very strange bug that seems to corrupt the stack when I call a function with several parameters which also declares some local variables.
Using this code:
struct mallinfo info = mallinfo();
printf("Memory in use: %d bytes\n", info.usmblks + info.uordblks);
printf("Total heap size: %d bytes\n", info.arena);
The output is:
Memory in use: 160720 bytes
Total heap size: 165160 bytes
Well I do use some "new" allocations (around 160kb, yes) but Total heap size 165kb??? o_0 this is not correct right? (but it can explain my memory corruption problems though...)
165kb?? I'm doing something wrong or what t.t?
Well thanks ^^!
#144653 - Cydrak - Mon Nov 05, 2007 11:18 am
I fussed with this the other day, it seems to be normal behavior.
On a desktop OS, malloc() obviously must share memory with other apps, it can't just grab it all. Instead, it calls sbrk() to expand the heap. This is the size reported in info.arena (on the DS). It will always be at least a little bigger than your own allocs; malloc() requires some of its own. It could be a lot bigger if stuff was freed in the meantime.
If you want both used and free RAM, this might help:
| Code: |
#include <unistd.h>
#include <malloc.h>
extern u8 __end__[]; // end of static code and data
extern u8 __eheap_end[]; // farthest point to which the heap will grow
u8* getHeapStart() {
return __end__;
}
u8* getHeapEnd() {
return (u8*)sbrk(0);
}
u8* getHeapLimit() {
return __eheap_end;
}
int getMemUsed() {
struct mallinfo mi = mallinfo();
return mi.uordblks;
}
int getMemFree() {
struct mallinfo mi = mallinfo();
return mi.fordblks + (getHeapLimit() - getHeapEnd());
}
|
#167803 - a128 - Sat Mar 28, 2009 8:47 pm
| Cydrak wrote: |
If you want both used and free RAM, this might help:
|
THANKS !!! I just used your getMemFree in my application.....great!!!!!
#167806 - Dwedit - Sat Mar 28, 2009 9:46 pm
Just watch out, if you allocate something big, then something little, then deallocate the big thing, you're stuck with a big hole in free ram until you deallocate the little thing too.
in other words:
Allocate A[500,000 bytes]
Allocate B[200 bytes]
Deallocate A
You don't get the free ram back from A until you deallocate B as well.
So try to allocate things in the order you deallocate them if you don't want something like that to happen.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#167807 - nanou - Sun Mar 29, 2009 12:36 am
Are you sure that's right? The description of newlib's malloc suggests (to me anyway) that it will gladly reuse those old chunks. I think the real issue is that region A can't be used as part of a larger allocation because B is allocated between it and any future sbrk'd memory.
It's easy enough to test:
| Code: |
#define MALLOC_TEST_SIZE 500000
char *a, *b;
a = (char *)malloc(sizeof(char) * MALLOC_TEST_SIZE);
for(;;) {
b = (char *)malloc(sizeof(char) * MALLOC_TEST_SIZE);
if(b==NULL) {
throw_a_fit();
}
free(a);
a = b;
}
|
If I'm right that will go on forever without calling throw_a_fit(). (I'd have just tested a!=NULL in the for(), but I wanted to be more obvious than that.)
_________________
- nanou
#167821 - albinofrenchy - Mon Mar 30, 2009 12:22 am
I agree with nanou on this one, I think dwedit is thinking of sbrk's. They can only go up and down, but it will allocate space if it can find a cavity I believe.
Would be good to know if I'm wrong though.
#167824 - elhobbs - Mon Mar 30, 2009 2:22 am
this information is of limited use at runtime. it can only be used to tell if a malloc will definitely fail. it can not reliably tell if a malloc will succeed. fragmentation will limit the maximum contiguous size that malloc can return. the best way to tell if malloc will succeed is to call malloc. well, that and planning your working set size to not exceed your resources.