memory menagement routines

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
where can I find some memory menagement routines like melloc()/free()
for very limited memory embedded system?

thanks

--
Mastupristi?

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

Re: memory menagement routines
On Mon, 12 Jan 2004 12:55:31 +0100, Mastupristi

Quoted text here. Click to load it

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.)


Re: memory menagement routines
On Mon, 12 Jan 2004 13:05:46 GMT

 
Quoted text here. Click to load it
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

Re: memory menagement routines

Quoted text here. Click to load it
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().

http://sourceforge.net/projects/xmk/.  Note: For just the memory management
routines, download: apl-0.0.x-compact.tar.gz.

Documentaton for C Library: http://xmk.sourceforge.net/apl/docs/doc.htm



Re: memory menagement routines
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
www.software-integrity.com



Re: memory menagement routines
On Mon, 12 Jan 2004 10:38:03 -0500

Quoted text here. Click to load it
What to you mean with "memory pools"? I dont' know wat they are so I dont' know
if they fit may needs.

thanks


--
Mastupristi?

Re: memory menagement routines

Quoted text here. Click to load it
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()






Re: memory menagement routines
On Mon, 12 Jan 2004 14:23:49 -0500

Quoted text here. Click to load it
thanks
to have a more detailed view where can I find more documents about memory pool?
There are some internet resources?


thanks
--
Mastupristi?

Re: memory menagement routines

Quoted text here. Click to load it
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"



Re: memory menagement routines
On Mon, 12 Jan 2004 10:38:03 -0500

Quoted text here. Click to load it
What to you mean with "memory pools"? I dont' know what they are so I dont' know
if they fit my needs.

thanks


--
Mastupristi?

Re: memory menagement routines
Quoted text here. Click to load it

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 snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: memory menagement routines
Hi, you should also mention that these routines are the quickest way to ensure
that your project never works.

Re: memory menagement routines
no-one@dont-mail-me.com (Robert Scott) writes:

Quoted text here. Click to load it

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)

Re: memory menagement routines
Quoted text here. Click to load it


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


--
    mac the naf

Re: memory menagement routines
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: memory menagement routines

Quoted text here. Click to load it

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

sdcc.sf.net

Kind regards,

Jan

Re: memory menagement routines
On Mon, 12 Jan 2004 12:55:31 +0100, Mastupristi

Quoted text here. Click to load it

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

---
42Bastian
Do not email to snipped-for-privacy@yahoo.com, it's a spam-only account :-)
We've slightly trimmed the long signature. Click to see the full one.
Re: memory menagement routines
On Mon, 12 Jan 2004 12:55:31 +0100, Mastupristi

Quoted text here. Click to load it
I wrote an articles on memory management for Embedded Systems
Programming magazine. See the link from
http://www.panelsoft.com/articles.htm . 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 http://www.panelsoft.com/murphyslaw . 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 http://www.panelsoft.com

Site Timeline