If malloc(), realloc(), free() have been implemented (and no reason they haven't I would think) then they will work the same as on an AVR or most other chips. What do you want to know about them?
There are no issues with using malloc() but realloc() and free() can give you a lot of grief.
I wonder if parameters about memory allocation are adjustable in due.
I found out there are several parameters I can adjust for the memory allocation in the avr source code.
(like minimum chunk size. In the avr, minimum chunk size is the size of a pointer and my application always allocates memory bigger than a pointer. This will make un-usable free blocks and cause fragmentation problem + performance degradation)
I can implement my own heap and allocation functions, but I thought using the existing one would be better for the code size.
Is it possible that I adjust parameters about memory allocation in due?
Not an answer - more of a philosophical point.
In my opinion (and it is only that), if you need dynamic memory allocation in an embedded system then you are probably taking the wrong approach.
The problem is that you need to ensure that the memory allocation AND deallocation are guaranteed to work in all circumstances, making sure that memory fragmentation never occurs. Any memory fragmentation will build up over time and stop your system working.
You need a fairly complex deallocation scheme that will merge adjacent free memory allocations and also ensure that all dynamic memory is returned after every "cycle" so there is absolutely no memory leakage. Performing that type of deallocation can be non-deterministic (in time - the execution time depends on the degree of fragmentation) which can impact on responsiveness for the rest of the system.
I had a recent example of a command processing function (I won;t explain why!) that had all of the "right characteristics" I've mentioned and the heap was kept fairly clean after each cycle. However I realised that I was actually allocating a number of differently sized but fixed blocks of memory and that a much simpler set of arrays of blocks would do the job and never lead to any chance of fragmentation. Also releasing and resetting the whole system became trivial (reset an index to 0!) and has stood the test of time.
Susan
