ipaq3115
Registered: 12/11/11
Posts: 139
|
|
Posted 26/05/12
|
#1
|
|
|
You should be able to see pretty clearly from my example.
If you open file1 then file2 when you close file1 the memory doesn't free up until file2 is also closed.
If you close file2 first then file1 memory frees normally.
The problem I initially had was that I only had ~500bytes of free memory and when the file1 close failed to free memory, then the next time I try to open the file it crashes because it wants another ~600bytes or whatever.
I have the latest R28 pmmc on a uOLED 28.
Attached Files
 testt.4dg (1.31 KB, 5 views)
|
|
Loading...
|
|
meldavia
Registered: 18/03/07
Posts: 900
|
|
Posted 26/05/12
|
#2
|
|
That is not a bug, it is normal behaviour.
Remember that mem_Heap() returns the largest block available, not the total number of bytes available.
__________________
Regards,
Dave
|
|
Loading...
|
|
ipaq3115
Registered: 12/11/11
Posts: 139
|
|
Posted 26/05/12
|
#3
|
|
Ah, okay, that makes sense. So, why can't it load back where it was before? Just because it isn't part of the largest block?
Sorry if these are noob questions, I'm still learning how the stuff in the background works.
|
|
Loading...
|
|
meldavia
Registered: 18/03/07
Posts: 900
|
|
Posted 28/05/12
|
#4
|
|
If you were to open another file, it should 'fill the hole' that is left, but that is not always the case, eg if you change fonts, or do any graphics in between,
some of that block may become used.
Memory management can seem to behave oddly at times, but in its wisdom it keeps track of smaller chunks, rejoining what it can to make larger blocks.
For your interest, the attached program does its best to try and break the memory management scheme.
In practise, this prog should run forever without breaking.
Attached Files
heaptest.4dg (3.72 KB, 6 views)
__________________
Regards,
Dave
|
|
Loading...
|
|
