embedded dropbear (more)...

Fabrizio Bertocci fabriziobertocci at gmail.com
Tue Apr 16 05:47:13 WST 2013


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.sutter at 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ucc.gu.uwa.edu.au/pipermail/dropbear/attachments/20130415/9441c062/attachment.htm 


More information about the Dropbear mailing list