public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: John Dallaway <john@dallaway.org.uk>
To: Mandeep Sandhu <mandeepsandhu.chd@gmail.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: [ECOS] Re: ecos mem footprint with HTTPD support
Date: Thu, 16 Jul 2009 18:30:00 -0000	[thread overview]
Message-ID: <4A5F71C6.9060608@dallaway.org.uk> (raw)
In-Reply-To: <b18c5f790907160154j6bbcbe8lc8865b3340223312@mail.gmail.com>

Hi Mandeep

Mandeep Sandhu wrote:

> I think I was wrongly calculating my RAM usage for the sample HTTPD
> app (using lwIP).
> 
> When looking for the runtime RAM usage of my app+kernel...I should
> add the bss+data+rwdata (if any) sections...right?

Yes, for eCos applications built for ROM startup. There will also be a
small area of RAM reserved for various vectors.

> .text and .rodata will reside in the flash only. Am I correct in this
> assumption?

Yes, for eCos applications built for ROM startup. The Flash will also
hold the original copy of the pre-initialised static data which is
copied to RAM at startup (.data section).

Note also that a few small fragments of _code_ are also relocated to RAM
(eg low-level Flash I/O code).

> Do all embedded systems work this way...i.e the code/text and rodata sections
> reside in the flash and rest is loaded into the RAM?

They should do when configured for ROM startup.

> Who maps these addresses?
> The linker script?

Correct.

> Also, any tips on how much space I should keep for expansion of the RW
> area's?

There is no expansion of the linker-defined sections. Thread-local
variables are stored on the thread stacks. These stacks are typically
allocated as static arrays. Some packages use their own
statically-allocated memory pools. You must decide how large these
stacks and memory pools need to be where necessary.

If you must use malloc() and related functions, the eCos dynamic memory
allocation package will allocate memory from the heap. The heap
typically occupies all remaining RAM above the application code and
data. Clearly, allocations from the heap are additional to anything
known to the linker and reported by the "size" tool.

> Say my bss+data+rwdata comes to around 55KB...is it safe to go with a
> system with 64KB on-chip RAM? Is 9KB margin safe enough?

You need no margin at all if you avoid dynamic memory allocation.

I hope this helps...

John Dallaway

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  parent reply	other threads:[~2009-07-16 18:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-15 10:37 [ECOS] " Mandeep Sandhu
2009-07-15 11:06 ` [ECOS] " John Dallaway
2009-07-15 13:14   ` Sergei Gavrikov
2009-07-15 13:18     ` Mandeep Sandhu
2009-07-15 13:53       ` Sergei Gavrikov
2009-07-15 14:05         ` Mandeep Sandhu
2009-07-15 14:17           ` Sergei Gavrikov
2009-07-16  8:54             ` Mandeep Sandhu
2009-07-16  9:10               ` Sergei Gavrikov
2009-07-16 18:30               ` John Dallaway [this message]
2009-07-17  8:24                 ` Mandeep Sandhu
2009-07-15 13:16   ` Mandeep Sandhu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A5F71C6.9060608@dallaway.org.uk \
    --to=john@dallaway.org.uk \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=mandeepsandhu.chd@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).