CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
Limits to malloc()?

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
dpaul



Joined: 15 Mar 2005
Posts: 12

View user's profile Send private message

Limits to malloc()?
PostPosted: Thu Oct 19, 2006 4:34 am     Reply with quote
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

View user's profile Send private message Visit poster's website

PostPosted: Thu Oct 19, 2006 11:59 am     Reply with quote
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

View user's profile Send private message

PostPosted: Wed Jan 31, 2007 5:34 am     Reply with quote
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

View user's profile Send private message

PostPosted: Wed Jan 31, 2007 9:59 am     Reply with quote
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... Shocked
treitmey



Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Jan 31, 2007 11:53 am     Reply with quote
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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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