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. I'm not sure if this will fit your purpose. Just tossing it out for discussion. Regards -Bill Knight R O SoftWare Quintin Beukes wrote: > 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 wrote: >> 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 isn't >> a need to dynamically allocate memory. Asking for dynamic memory allocation >> is a warning that the system wasn't architected with the small system >> mindset. There's usually a way around dynamic memory if you think about the >> problem differently. >> >> 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. >> >> >> ******************************************************************** >> Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products >> (978) 742-9014. Gold 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