Use of malloc and calloc

[ep.hobbyiest]

Hi,
In embedded where we can make use of malloc and calloc function?
I know the concept of malloc and calloc, but i am finding out the exact application in embedded as well as outside.

 

[horace1]

you would use malloc and calloc in situations where you don't know the size of your date sets until run time. Allocating arrays etc at compile is OK if you how large they will be - if not they may end up too large wasting memory or too small and the program fails. Clearly one has to check the return value from malloc or calloc to ensure that memory was allocated taking some appropriate action if they have failed (error message on LCD, flashing red LED, etc)
In embedded systems programming I rarely use them - I tend to know the size of arrays etc when the system is specified

 

[doraemon]

Hello!

As an addition to what Horace1 replied, I would add this:
It's difficult to generalize what you should do in embedded system. A pic 16 is an embedded system,
and a Cortex A6 is (can be) an embedded system.
Basicaly, if your compiler swallows malloc, then you can use it. Otherwise, you have to write your
own brew, which is not a simple task.
Beside this, in all help requests you will find on this forum (well, let's say 99.9%), you don't need
a memory allocation, and using one is just looking for trouble.

Dora.

 

[andre_luis]

And we can avoid the need of dynamic allocation of the memory with Malloc declaring variables inside nested functions, so that once exiting the function, their addresses are automatically released.

 

[doraemon]

Hello Andee!

And we can avoid the need of dynamic allocation of the memory with Malloc declaring variables inside nested functions, so that once exiting the function, their addresses are automatically released.

I'm not an expert in compilers, how they work and so on, but I made a program a long time ago with an array inside of a function, exactly for this purpose. But the drawback is that it was eating stack, therefore the simple fact of calling the function took quite some time. Since I noticed that, I started using a memory pool at a given location. Of course, it can be dangerous because any part of the program can have access to this memory pool, but in an embedded system, it can be easy to manage if you take care of what yo do.

Dora.

 

[Aussie Susan]

One of the biggest issues with the whole 'malloc' family of functions is the fragmentation of the pool.
One reason people want to use dynamic memory allocation is that they don't (or cannot) know the size of a memory allocation at compile time.
However you are totally dependent on the skill of the function writers as to how the memory is allocated and then re-merged back into the pool when freed.
Considering that the characteristics of embedded devices include small RAM and ROM allocations, there is pressure to write the simplest routines possible but this typically leads to pool fragmentation. Another characteristic is that embedded systems are supposed to 'run forever' which means that ANY fragmentation will almost inevitably lead to memory exhaustion and (presumably) a crash/restart.
You can write more sophisticated pool management functions but these take more code and longer execution and still cannot guarantee that memory will be available when requested.
An approach I've taken in the past is to create blocks of memory that are of fixed size so that allocation and release will be relatively simple. (If the memory blocks are of too greater a size difference then I've used multiple pools). You can then create a 'union' that represents all of the actual structures you want to hold that are up to the size of the memory block and access the dynamically allocated memory through those.
However, I typically find that it is possible to re-think the approach so that dynamic memory allocations are not required and you can use standard data structures to achieve what you need.
Susan

 

[ep.hobbyiest]

Thanks Dora and Aussie.
I m agree with you but i think when we are using RTOS or Embededd OS then we can use malloc, right?
and no need to use it in simple firmware without rtos.

i also never use this kinda allocation yet. But i m using rtos so i think i will need this.

 

[Aussie Susan]

I've used FreeRTOS and there are 5 different versions of the 'malloc/free' equivalent functions with at least 2 of those covering the points I made above about pool fragmentation. Don't use the simplistic versions or you will have problems eventually.
However, whether you use an RTOS or embedded OS has nothing really to do with the need to use dynamic memory allocations - that lives firmly in the domain of the program task(s) you are writing and the work they are doing. For example, I've seem people argue that they need dynamic memory for text lines that are read in from a UART as they have no idea how big to make the buffers before they see the line terminator; this is what ring buffers are for and/or having fixed sized buffers, possibly in a linked list etc..
Out of laziness I did use dynamic memory for a command line parser app (running under FreeRTOS) that I ported almost directly from a PC but it was also designed so that memory was freed in the opposite order to it being allocated which allowed for simpler memory block merging algorithms to be used. Even there most of the allocations were for fixed sized 'structs'.
Of course, if you are using an RTOS etc. then you also need to ensure that the dynamic memory functions are thread-safe or you will end up with memory corruptions from that source alone.
Susan