Malloc, etc...

Has anyone found a way to allocate memory for a type with MCC18.
I’ve only used the standard ways around malloc like static variables and arrays to get pointers to create a list of pointers. I’ll have to look into this more, but I was wondering if anyone knew off the top of their head, maybe an assembly trick or something. If no one knows how I’ll just try to find out, there seems to be a lot of memory setting for strings.

Oh yeah, I couldn’t find malloc or calloc, it’s driving me crazy, C WITH NO MALLOC AAAAAAAAAAAAH!

Ryan Waliany

the documentation on this can be found in the following document:

Thanks for the link, but can the documentation be found there? If so, I don’t see it. They tell you how to use strings, etc… But they do not show you how they’re memory allocation for their strings work. I suppose they don’t except anyone to use it, so they didn’t explain how?

I’m talking about like

typedef struct ptr PTR;

typedef struct
int value;
PTR *next, *prev;
} ptr;

PTR *temp;

how to create memory that is not deleted after the function is executed besides a static declaration, or a global declaration of an array.

I would like to know how to do like , temp = (PTR*)malloc(sizeof(PTR));

I could have sworn there is a section on memory allocation in there somewhere. I think i recall readign this somewhere in the above document.


As a firmware developer by trade, we don’t tend to use malloc in real embedded applications. The trouble is that there just isn’t room for linked lists and other non-static memory uses.

If you need a list I would suggest a global queue or stack of a static size (10 to 20 items [or even an array]). This is to ensure other parts of your application get the memory they need. Now to get into the data hiding aspect that you probably want, make a few accessor functions to this global item (GetValue and PutValue) that handle talking to the global structure.

The reason for this is that the stack needs to be protected and if a link list goes wrong it could corrupt all sorts of memory. Another reason is that embedded applications just don’t have the memory management code in them to handle malloc and free.

-Jim Wright


Just to amplify what Jim said, malloc() is really, really evil for small, embedded systems. It’s a better practice to allocate all memory at run time (the stack is a special case) so that you are guaranteed to live (execute) within your means. For many reasons (e.g., fragmentation), memory managment without a real hardware memory managment unit (MMU) is a really tough problem. The size of the stack can be tweaked by initializing the stack to a fixed value (not zero) at runtime (see _startup() in ifi_startup.c), exercising all aspects of your code, and then examining the stack space to see where the “high water mark” is located. If you see that you came really close to using all of the stack space, you can allocate more at run time. Conversely, if you have a bunch of unused stack, you can free up some of that memory for other uses.


Thanks, very helpful.