Hmm interesting... now, 77K is kind of 'at reach'... Depending on the chip I am going to finalize the project, but probably with some help from some external RAM & flash I might give it a shot. Thanks a lot for your reports! Fabrizio
On Mon, Apr 15, 2013 at 5:30 PM, Ed Sutter <[email protected]>wrote: > One correction... > I realized that I reported my high-water mark with my allocator > in 'trace' mode. This significantly screws up the allocation sizes in > runtime. After rebuilding with that turned off, the high-water mark > that I get is around 77K. > > Hi, >> Just to put a few things in perspective regarding the likelihood of this >> working in a really small embedded system... >> >> Regarding memory... >> It really depends on just how small you need to be... >> >> One session looks like it uses upwards of 2100 malloc calls. Long term >> fragmentation from one session to the next is not an issue simply because >> I >> have a dedicated heap, which I flush at the end of each session; however >> my heap analytics show that the high-water level is under 200K of heap. >> I'm hoping that some of these allocations can be replaced with >> stack-based arrays, >> but I haven't looked into that much yet. >> >> Regarding speed... >> No "real" data here, other than to say that I'm on a ~450Mhz PowerPC (no >> FPU) >> and it seems to be fine. >> >> >> Ed >> >> >> >
