Careful use of dynamically allocated memory can make sense in an embedded 
application. As examples, I will document the way dynamic memory is used in 
three large embedded systems I have developed (one in assembler, one in C 
and one in C++) that all use carefully managed dynamic memory allocation. It 
is interesting to note that several techniques, as outlined below, can be 
used to avoid the twin bugaboos of fragmentation and memory exhaustion. 
Admittedly all of these systems have much more memory than a PIC.

The assembler program always allocates memory in one page (256 byte) 
increments, larger structures are kept as linked lists of these pages. When 
memory runs out various caches are emptied and returned to the free memory 
pool. This is done by the memory allocator in a way that is transparent to 
the application. The design of the system is such that memory cannot be 
exhausted completely. This system is fragmentation proof (because all 
allocations are for the same size block), exhaustion proof (because cache 
data can always be returned to the free pool) and has run for years and 
years without trouble.

The C program does most of its dynamic allocation at startup. The remaining 
allocations are handle-based and thus can be moved around in memory to avoid 
fragmentation. Again, memory exhaustion is avoided by returning 
least-recently-used data to the free pool. This system is fragmentation 
proof (because of the handle-based allocation), exhaustion proof (because 
lru data is returned to the free pool when needed) and has run for years and 
years without trouble.

The C++ program is perhaps the most interesting. It uses a custom allocator 
so that "new" operations are always taken from one of several pools of 
memory, each of fixed size elements, thus making fragmentation impossible. 
In this case exhaustion is avoided by simply having more memory available 
(several megabytes) than a careful calculation of maximum usage (verified by 
'worst case' testing to be less than a megabyte) shows is needed. [Note that 
I am not 100% happy with this, sometimes 'worst case' isn't the worst case]. 
Again, this program has run for many years.

-- Bob Ammerman
RAm Systems

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist