 |
 |
| View previous topic :: View next topic |
| Author |
Message |
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| Limits to malloc()? |
 Posted: Thu Oct 19, 2006 4:34 am |
 |
|
Greetings:
I have just spent time writing a simple, dynamically allocated linked list. I wrote and debugged the code in its own mini-project (Compiler 3.249). When I included the .C and .H files in a much larger project, malloc() always returned a NULL.
Back to the drawing board! I created the following program to test the behavior of malloc().
| Code: |
//* MallocTest.c ************************************************
#define DEBUG
#include <18F252.h>
#device *=16
#device ICD=TRUE
#fuses HS,PUT,BROWNOUT,NOWDT,WDT64,NOPROTECT,NOLVP
#zero_ram
#include <stdlibm.h>
//* bogus low memory data space used ***************************
int8 BogusRAMWaste [ 225 ];
//************************************************************
void Main ( void )
{
int8 *p;
p = malloc ( 0x10 );
if ( p != NULL )
{
memset ( p, 0xEE, 0x10 );
free ( p );
}
while ( TRUE )
{
}
return;
}
//************************************************************
|
This program demonstrates malloc() works so long as the array BogusRAMWaste[] is less than 224 bytes long. If BogusRAMWaste is declared [224], malloc() locked up and never returns. If BogusRAMWaste is declared greater than 224 bytes, malloc() always returns a NULL pointer.
This test, and my full project, suggests dynamic memory allocation is somehow limited to low data space. Or, is there something obvious I am missing here? I've stepped into malloc(), and it seems the limitation is when __DYNAMIC_HEAD is setup, and I've not figured out quite where that is done. In STDLIBM.H, the node_t structures used by malloc() et al. have 16- bit pointers, but it almost seems like they are behaving as 8-bit. Or perhaps dynamic memory allocation only works on the PICs in specific, limited memory space?
Thanks for any suggestions to get around this limitation. I can certainly fix a buffer space to get around this problem, but dynamic memory allocation would better suit my purpose.
Doug |
|
 |
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Thu Oct 19, 2006 11:59 am |
|
|
I think that malloc has to find continuous memory space in a given bank.
((No bank swapping))
The spec pg 44 says that the memory is 16 banks of 256 each.
That will be your limit.
BTW I never use malloc. Use the memory efficiently, in functions, and let
the compiler take care of re-using it. |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Wed Jan 31, 2007 5:34 am |
|
|
| treitmey wrote: | I think that malloc has to find continuous memory space in a given bank.
((No bank swapping))
The spec pg 44 says that the memory is 16 banks of 256 each.
That will be your limit.
BTW I never use malloc. Use the memory efficiently, in functions, and let
the compiler take care of re-using it. |
Hi treitmey,
I think I may have just had a similar problem although strangely it has been working for me (allocating 1352 bytes) successfully for some time.
What would you suggest is an efficient way of allcating 1352 bytes of RAM? (PIC18F4620) - I need to read this data from external FRAM.
I need to read various sizes of data in different places throughout the program so thought that dynamic allocation would be best. Is this more suitable than malloc?
char some_ram[1352];
Thanks. |
|
|
Martin Berriman
Joined: 08 Dec 2005
Posts: 66
Location: UK
|
|
| Posted: Wed Jan 31, 2007 9:59 am |
|
|
| treitmey wrote: | Can you explain a little more about what you are trying to do.
Normally you need a buffer the size of the largest data you are working with. |
Hi, I am reading a logo from FRAM that is 1352 bytes in size. I am then displaying the logo on a graphics LCD.
I was originally allocating dynamic memory however I seem to have found a problem in stdlibm.h - described in another thread.
I have changed my program now so that I simply declare an array of 1352 bytes in the function and use that instead; it works fine, just wondered whether that was the most efficient way with the CCS compiler.
I don't currently have time to try and find the apparent bug in stdlibm.h but then it looks from other comments on the forum as if malloc is not terribly stable and not a good idea for embedded CCS stuff - unless that is a historical problem that is now fixed.
Best Regards
Edit: Hmm - Spooky. Not sure where your post went...  |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Wed Jan 31, 2007 11:53 am |
|
|
I saw your other thread and thought you were getting the answer there.
I would only read say 32 bytes from the FRAM at a time. then write to the LCD. and repeat..
Then the 32 bytes could be local to the function. And when the function exits.. all the memory is released/reused.
OR since these are different busses. ((LCD, FRAM)) read only 1 byte and send
it to the LCD. No memory array needed at all. But there is a little overhead
in the I2C header for reading FRAM 1 byte at a time |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
