Gerhard Fiedler escreveu:
> Bill Knight wrote:
>
>   =

>> Quintin Beukes wrote:
>>     =

>>> On Tue, Oct 6, 2009 at 5:39 PM, Olin Lathrop <olin_piclist@embedinc.com=
> wrote:
>>>       =

>>>> Another drawback of dynamic memory on a small system is how to
>>>> guarantee you won't run out.  If you don't know how much memory you
>>>> need up front, then how do you know you don't need more than there
>>>> is available under the right set of input conditions.  And if you
>>>> do use malloc or the like, what are you going to do when it fails? =

>>>> Punting back to the operating system with a non-zero exit status
>>>> doesn't work here.
>>>>         =

>>> Though so far I've not been able to come up with a solution for a
>>> specific problem where the mode of the device can change and so the
>>> data it stores changes. Though both structures sometimes need
>>> memory, depending on it's status. We basically solved it by
>>> overlaying the same structure over a memory block and giving it an
>>> ID to know what to cast to, though 2 dynamically sized linked lists
>>> would have been the ideal solution here.
>>>       =

>> One of the problems with malloc & free is memory fragmentation due to
>> the variable size of the blocks that are allocated and released.
>> Another approach that is often used in embedded systems is a memory
>> pool of fixed sized blocks where the size of the blocks in a given
>> pool is large enough to hold all of a specific item item.  If an item
>> is somewhat smaller than a block, it just doesn't use all of it.  The
>> result is still much safer.  If you need both big and small blocks
>> then have the small block manager get a big block from the big block
>> allocator and divide it into small fixed size blocks.  If it needs
>> more small blocks, have it get another big block and divide it.
>>     =

>
> Another approach could be a union of two arrays with different member
> types. No list =3D> no dynamic allocation needed. Array =3D> can be used =
as
> circular buffer or stack. Overall union (as opposed to individual union)
> =3D> all the available space is used (in case the types have sufficiently
> different sizes that this makes a difference).
>
> One of the main issues here is that dynamic memory is not predictable.
> Usually you need to make sure that in the worst case scenario (per spec)
> the available memory is enough (queue length, etc.) With dynamic memory,
> you don't even know before-hand how much usable memory you have, due to
> fragmentation. Only a 'designed' memory solution can give you that. With
> this in mind, malloc et al is generally out of the picture anyway.
>
> Gerhard
>   =


Not always true. I have a system where there are a few types of dynamic
data, and all of them have fixed sizes.
What changes is how many of each type is needed at any time. And
sometimes when one type is in use, by design, other types are not needed.

Another example, to avoid priority inversion I have a queue of messages
(real text messages, for LCD). The message length may vary from a couple
up to 32 bytes, but I always allocate in multiples of 16 bytes.

Best regards,

Isaac

__________________________________________________
Fa=E7a liga=E7=F5es para outros computadores com o novo Yahoo! Messenger =

http://br.beta.messenger.yahoo.com/ =

-- =

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