<div dir="ltr">Hmm interesting... now, 77K is kind of 'at reach'... <div style>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.</div>
<div style>Thanks a lot for your reports!</div><div style>Fabrizio</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 15, 2013 at 5:30 PM, Ed Sutter <span dir="ltr"><<a href="mailto:ed.sutter@alcatel-lucent.com" target="_blank">ed.sutter@alcatel-lucent.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">One correction...<br>
I realized that I reported my high-water mark with my allocator<br>
in 'trace' mode. This significantly screws up the allocation sizes in<br>
runtime. After rebuilding with that turned off, the high-water mark<br>
that I get is around 77K.<div class="HOEnZb"><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
Just to put a few things in perspective regarding the likelihood of this<br>
working in a really small embedded system...<br>
<br>
Regarding memory...<br>
It really depends on just how small you need to be...<br>
<br>
One session looks like it uses upwards of 2100 malloc calls. Long term<br>
fragmentation from one session to the next is not an issue simply because I<br>
have a dedicated heap, which I flush at the end of each session; however<br>
my heap analytics show that the high-water level is under 200K of heap.<br>
I'm hoping that some of these allocations can be replaced with stack-based arrays,<br>
but I haven't looked into that much yet.<br>
<br>
Regarding speed...<br>
No "real" data here, other than to say that I'm on a ~450Mhz PowerPC (no FPU)<br>
and it seems to be fine.<br>
<br>
<br>
Ed<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br></div>