Fabrizio,
Don't ignore CPU horsepower needs.
Ed
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
<ed.sut...@alcatel-lucent.com <mailto:ed.sut...@alcatel-lucent.com>>
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
