It's very true what you say. I think I did mention it, but rethinking
all my problems where I felt like using malloc ended up in an
alternative, though less elegant (another word for "big system"
perhaps? ;>).

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.

We have an SD card and allocate a large array to store a certain
amount of blocks, flushing them as they are written to make space in
the array, like when we need more of a certain structure, which is
itself slow both times, as you don't only replace items (due to their
very different sizes), when you clean old items you have to shift the
array data. If you had a more dynamically sized linked list, we could
gain a lot of performance if these structures could be more dynamic,
and only flush to SD card "cold" data when more memory is needed.

I'm sure many solutions could be thought up for these, as have been my
experience so far when I think about them "embedded-ly" a bit more,
but given the way the systems work a lot could be gained in both there
cases with semi-dynamically sized structures, by which I mean they
share memory, but can allocate/free like with malloc() and free().
Almost like a smart union, and together with the SD card you keep in
memory the "hot" data.The SD card is very slow, and network + RF
transfers as well. With a bit of multitasking and a some "dynamic
caches" (perverted the meaning a bit - sorry) the system could work
much more optimally. We for instance have a problem that where the RF
transfers happen they need to happen very fast, and the restructuring
of the array to make space, and a lot of flushing to/from SD card in
between wastes a lot of time. Same goes for reading from the SD card
when sending back over the network. If this happens with the "other
than to be transfered" structure mostly in memory because of a
previous "exchange which overwrote it's data", it's almost purely
reading from the SD card. Reading into dynamically allocated areas and
freeing as you go could help, especially when the hot data is
available and as you start writing to the network port you can start
reading from the SD card, using what is available in RAM while you
wait for new data.

But like discussed, there is a lot involved, and I understand the
implications/constraints. I haven't gotten around to analyzing the
system yet (only a few thoughts/looks here/there and an RF data
structure optimization once), but from initial impressions this might
be a possibly justified use of dynamic allocation.

Quintin Beukes



On Tue, Oct 6, 2009 at 5:39 PM, Olin Lathrop <olin_piclist@embedinc.com> wr=
ote:
> Tamas Rudnai wrote:
>> BTW: I think what Olin is trying to express is that a dynamic memory
>> allocator needs an overhead plus some trouble with the memory
>> fragmentation so overall it is not the best choice for a small device.
>
> Yes, and usually small embedded systems run fixed problems where there is=
n't
> a need to dynamically allocate memory. =A0Asking for dynamic memory alloc=
ation
> is a warning that the system wasn't architected with the small system
> mindset. =A0There's usually a way around dynamic memory if you think abou=
t the
> problem differently.
>
> Another drawback of dynamic memory on a small system is how to guarantee =
you
> won't run out. =A0If you don't know how much memory you need up front, th=
en
> how do you know you don't need more than there is available under the rig=
ht
> set of input conditions. =A0And if you do use malloc or the like, what ar=
e you
> going to do when it fails? =A0Punting back to the operating system with a
> non-zero exit status doesn't work here.
>
>
> ********************************************************************
> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
> (978) 742-9014. =A0Gold level PIC consultants since 2000.
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

-- =

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