memory menagement routines

First you should re-examine your need for dynamic memory management. In very limited memory embedded systems, the application is usually small enough that you can do a better job with static memory management. For example, the CCS C Compiler for Microchip controllers examines all the auto storage class variables and examines the complete project function call tree. Then it decides which static allocations can be made for the auto variables so that no function will have his auto variable trashed when he calls another function. Of course if you have a controller with a real data stack, that is a good way to allocate memory.

-Robert Scott Ypsilanti, Michigan (Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

There is an example available in the SDCC source code (under the library routines)

sdcc.sf.net

Kind regards,

Jan

We use Renesas h8s 2633... Usually we use only its 16KB internal sram, and in our applications we need to allocate a large number of little piece of memory. Sometimes we use the same processor with exernal memory (128KB at least) and we neet to allocate larger chunks of memory.

Now we use a rudimentary memory menagement system (we can do only 16 allocation in the worst case), so we want to improve it.

thanks

--
Mastupristi?

Posted from X-Privat Free NNTP server - www.x-privat.org

Hi, you should also mention that these routines are the quickest way to ensure that your project never works.

Static memory management is a good idea whenever possible. Dynamic memory management opens the Pandora's box of leaking and fragmenting memory. With static memory allocation you won't run out of memory.

We have an application with around 100 kB of code running in an ARM system (ARM7TDMI). Seven threads, including a graphical user interface, IP stack and a flash file system, etc. Not a very small embedded, but still no dynamic memory allocation.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

Here is link to an C library (targeted for 8/16bit micros) that provides malloc(), free(). It also provides memory pools (i.e. pools of fixed size memory blocks that can be allocated/freed). If you have to do dynamic memory allocation in an embedded system, **try to avoid it if at all possible**, then use memory pools. Memory pools work well for "pre-allocating" memory and for not having to worry about heap-fragmentation issues. If memory pools do not fit the application, then you are stuck with malloc()/free().

Note: For just the memory management routines, download: apl-0.0.x-compact.tar.gz.

Documentaton for C Library:

To the OP...

If you understand the issues concerning dynamic memory management in embedded systems, you can easily write your own routines. It's likely to be easier than writing your application - especially if you restrict yourself to pools of fixed-size blocks and don't have any mutual-exclusion worries.

If you don't understand the issues (fragmentation, etc.), don't use dynamic memory management. Alternatively, design, write and test the routines with great care. You'll probably be aware of most of the issues by the time you've finished!

Regards,

-- Peter Bushell

in a small embedded environment you may be able to support malloc() without free(), in which case memory management is trivial.

--
	mac the naïf

What to you mean with "memory pools"? I dont' know wat they are so I dont' know if they fit may needs.

thanks

--
Mastupristi?

What to you mean with "memory pools"? I dont' know what they are so I dont' know if they fit my needs.

thanks

--
Mastupristi?

know if they fit may needs.

Think of a memory pool being a single heap with the limitation that it can only allocate memory in pre-determined fixed size blocks. The fixed block size has two immediate benifits, 1) a given memory pool never suffers from fragmentation; and 2) Allocating and freeing a block is very fast and deterministic. The idea is then to have collection of memory pools, one for each desired block size.

For example lets say my application needs to dynamic create and destroy the following structures: struct Point3D { int x; int y; int z; }; struct Point2D { int x; int y; };

struct GraphicalDevice {...}; // Lots of stuf, for this example say sizeof(GraphicalDevice) == 64

Now, the application needs to allocate alot of Point3D and Point2D structures, but at most only 2 GraphicalDevice structs. Then you could setup three memory pools such that:

poolPoints2D:= blocksize=sizeof(Point2D), numblocks=M // what ever number you need poolPoints3D:= blocksize=sizeof(Point3D), numblocks=N poolGraphicalDevices:= blocksize=sizeof(GraphicalDevice), numblocks=2

any time you need memory for Point2D, then Point2D* p12 = memPoolAllocate( &poolPoints2D );

and then when you done with it memPoolFree( &poolPoints2D , p12 );

Note: the above allocate can still fail like malloc()

thanks to have a more detailed view where can I find more documents about memory pool? There are some internet resources?

thanks

--
Mastupristi?

pool? There are some internet resources?

I do know of any resources (other than source code). Try Google. The concept of "memory pools" does not have a universal name and/or label, so try phrases like: "memory pool" "memory partitions" "fixed block allocator" "fixed sized heaps"

If your application uses malloc/free/realloc, religiously checks the return values at all times, and knows just what to do (other than aborting) on failure, you should not need to worry about such usage. But beware of "try again later" solutions, because you may run into "deadly embrace" problems, otherwise known as deadlock. You will probably have to ensure that any allocations will eventually be freed, without conditions.

I had one such system that buffered and delivered messages to remote stations, which could fail. Every message had a time stamp, and was in a linked list. If the delivery failed (on the basis of the posted time) it was rerouted to a local printer and then purged. (The local wasn't allowed to fail!!) If allocation for a new message failed then the time criterion for purging messages was reduced, and list delivery retried. The systems ran for years with no failures, and delivered medical testing results to nurses stations.

Things were actually slightly more fail-safe. Each message had an alternate destination, which kicked in after primary failure. Alternate failure moved it to local output. Local output failure gave up and purged it, leaving a flag and lighting an error light. Never happened after initial testing when the fault was forced.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!

You should consider an RTOS, this (most often) gives you a deterministic memory management + thread/task controll.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

Only allocate or also free ?

If the type of these chunks is known, one or more simple arrays may do the job.

--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use @epost.de instead !

I wrote an articles on memory management for Embedded Systems Programming magazine. See the link from

This article discusses pools and some other techniques if you are concerned that a full malloc/free may introdue too much complxity.

I also wrote 2 articles on finding leaks when you are using the heap. See them at

They discuss pools The march and April 2002 articles are the ones you want.

regards, Niall Murphy

=========================== See the User Interfaces for Embedded Systems Page at