Vitaliy wrote:

> Gerhard Fiedler wrote:
>> This is exactly what I'm talking about. You need to "design" the
>> memory usage; you can't just use willy-nilly malloc/free the way
>> you'd do it in a typical desktop or server application. 
>> 
>> So, even if you use malloc/free, you need to design how much of your
>> memory is needed, worst-case, for every part where you use dynamic
>> memory, you need to design how much of it is needed in total,
>> worst-case, by all parts that use dynamic memory together, and you
>> need to design how heap fragmentation plays a role in that and make
>> sure that you have the memory available that you think you have.
> 
> Static memory allocation works great when your memory requirements
> are known upfront. 
> 
> However, there are applications where the memory requirements are not
> known upfront. In other words, in one case you may need to allocate
> 1k to ObjectA and 2k to ObjectB. In another situation, you need 0.5k
> for ObjectA, 3k for ObjectB, and 2k for ObjectC. You get the point. 
> 
> So what solutions are available that avoid static memory allocation? 
> The most straightforward way is to determine the maximum amount of
> RAM you need per object type, and allocate it at design time. This
> approach is wasteful, because you end up having to use a chip with
> more RAM than you actually need, or crippling the program's
> features/performance. Or, you can create arcane custom solutions to
> "emulate" dynamic memory allocation. 
> 
> With dynamic allocation, each object is allocated only as much RAM as
> it needs, and when the object is no longer needed the RAM can be
> freed and made available for other objects. 

All agreed, but this is probably a device that may fail if the memory it
needs isn't available -- typically because it has a user interface and
user configuration possibilities, and when it fails it's because the
user added too much functionality for the available memory. Your typical
small-micro embedded device may not fail within specified operation
constraints, and memory must be guaranteed to be available. Which
requires the memory design I was talking about.

These are two quite different scenarios, and probably should be
discussed separately. 

Or -- if I'm mistaken --, how do you guarantee that a program that uses
heap allocation doesn't fail (due to lack of memory) when operated
within specs?

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