Malloc

See K&R?

But, in embedded applications, it's usually best avoided.

I agree with Andrew. Allocating memory dynamically in an embedded application is not a great idea. You will eventually end up with too many fragments, and have to put in a routine to clean up the memory pool.

Unless you are seriously short of memory, you are better off declaring variables. Remember that the compiler will try and use internal registers for any variables declared within functions, and the linker will overlay wherever it can. Try using the OVERLAY directive in the linker and see how much impact it has. We have used the OVERLAY with the '51 toolset and it worked fine. You may have to play with the overlay options some to get it correct, but it's worth the effort I'd say.

With the cost of RAM these days, try using a bigger chip. With 'C' code, the days of small RAM segments is fast disappearing.

Yes, you have to have some sort of heap
handling system going.
A common implementation of malloc memory blocks is to put a struct like
typedef struct {
int size;
void * next;
}
just before the allocated memory.
The 'next' pointer is used for two things,
i) link together ALLOCATED memory blocks.
ii) when blocks are freed they are moved to a 'free' list with this pointer.

So when a call to malloc is made, the 'free list' is searched for a block that's equal or bigger size. If bigger, the block is split so that the remaining space is linked to the free list. Then the desired block is linked to 'allocated' list.

You see from this as mentioned i earlier post that this soon generates a lot of small free blocks (fragments) which have to be cleaned up and merged together eventually.
This can be bad for real-time and/or small applications.

A slightly simpler way is to have a system with fixed size(say 256 bytes) blocks available.
The something like 'void* getblock()'/'void free(void*)' can be implemented.
The memory manager routines then can keep track of these block with a bitmap for exeample (free/used).
The application of course has to be written with this in mind.

You are all right that malloc and free are usually bad for embedded systems.

The memory allocation routines from Keil are a direct implementation of the Knuth memory allocations described in "The Art of Computer Programming".

The most important part of this implementation (in my opinion) is that the free function re-joins adjacent free memory blocks. So, for example, you can allocate all of the memory (in small pieces), free it all, and then allocate a big block -- and it will work!

You must provide the address and size of the heap to the memory allocation initialization code. This is easiest done by creating a large array and passing the address and the sizeof the array.

Anyway, with a little forethought and management, you can use malloc/free in an embedded program.

Jon

A slightly simpler way is to have a system with fixed size(say 256 bytes) blocks available.
The something like 'void* getblock()'/'void free(void*)' can be implemented.
The memory manager routines then can keep track of these block with a bitmap for exeample (free/used).
The application of course has to be written with this in mind.




Taking your example of setting 256 bytes. How do I go about setting it using the void *getblock() and void free(void*) function..

Thanks..

If you dynamically-allocate, it means you'll have to access your dynamic data via pointers. This is probably less efficient than direct addressing - especially for structures!