Looking for a tools to report memory usage

Good point. It seems that I have to stick with the same compiler and
linker.

On Mar 12, 11:58=A0am, Hans-Bernhard Br=F6ker <HBBroe...@t-online.de>
wrote:
> On 11.03.2011 05:23, Like2Learn wrote:
>
> > I have a legacy embedded product written by C under IAR workbench. I
> > want to know how much memory the program will consume on-the-fly, so I
> > can decide a suitable size of SDRAM for it, not too small to affect
> > the performance, while not too big to affect the BOM.
>
> Because pretty much everyone using a compiler for embedded targets wants
> to know that, every linker worth its salt reports that in its map file.
> =A0 Your bad if the legacy code base wasn't stored along with the origina=
l
> map files.
>
> > I don't have IAR workbench installed yet. Is there any tool that can
> > help me to estimate the memory usage of a program even without running
> > it in the target hardware? It sounds like I am requesting a dynamic
> > software analysis ability from a static analysis tools.
>
> No, you're requesting you get that compiler _now_. =A0The only static
> analysis tool that will reliably reproduce the memory allocations of an
> actual compiler and linker are that same compiler and linker.

[If you "Like to Learn", then consider learning about the
disdain for TOP POSTING!]

On 3/14/2011 4:15 PM, Like2Learn wrote:
 >>> Any other idea for the task?
 >>
 >> Since it is a "legacy embedded product", it already exists and is
 >> (or was) in production.  Why not look at the bill of materials and
 >> see how much physical memory it *had* previously?

> Cause my boss and I are cheap, and we want to cut the BOM cost by
> using slower CPUs and use less RAM.

So, you've already looked at the existing RAM complement and
decided that smaller devices *are* available and *are*
economically feasible (?).

In which case, spend your NRE dollars figuring out how to save
your recurring dollars!

[think:  time, elbow grease, ...]

On Mon, 14 Mar 2011 16:13:12 -0700 (PDT), Like2Learn
<like2learn@live.ca> wrote:

>I found out and checked the map file. Thanks!
>However, this application deals with network, and quite some memory
>are allocated dynamically, so the map file won't reflect the true RAM
>usage. Possibly the only way to check the RAM usage is to trace and
>debug the application.

At start-up, fill the RAM with some (non-zero) pattern like 0xDEADBEEF
and after a year of continuous operation, check what is still
undisturbed.

A simple (non-threaded) OS will typically use the RAM with a stack
from the top of the RAM downwards and the heap starting at the bottom
of the RAM upwards.

Like2Learn wrote:
> I have a legacy embedded product written by C under IAR workbench. I
> want to know how much memory the program will consume on-the-fly, so I
> can decide a suitable size of SDRAM for it, not too small to affect
> the performance, while not too big to affect the BOM.
> 
> I don't have IAR workbench installed yet. Is there any tool that can
> help me to estimate the memory usage of a program even without running
> it in the target hardware? It sounds like I am requesting a dynamic
> software analysis ability from a static analysis tools.
> 
> BTW, is there any tools in IAR workbench that can report the memory
> usage of a running program? I am not familiar with IAR.
> 
> Any other idea for the task?
> 
> Thank you.

For the last question, you should be do it without any fancy tools. If
you are dynamically allocating memory, then you just write a function
within the system mainloop, or an added task if rtos, which continuously
outputs stack and heap values, free pool sizes, whatever. You may need
to init the ram with an odd value first and restart for every run, but
the rtos or allocator may have this data accessable anyway. Then, just
put more and more load on the system until you get the info you need.

Even the smallest system can benefit from a syslog() type facility that
is designed in from the start, showing what the system is doing while
running and typically only needs 10's of lines of code to implement on a
simple system...

Regards,

Chris

Hi Chris,

On 3/15/2011 3:36 PM, ChrisQ wrote:

> For the last question, you should be do it without any fancy tools. If
> you are dynamically allocating memory, then you just write a function
> within the system mainloop, or an added task if rtos, which continuously
> outputs stack and heap values, free pool sizes, whatever. You may need

Easier to instrument your memory manager.  Let it track maximum
total allocation and store this internally -- report it when
appropriately "kicked" (e.g., SIGHUP).

> to init the ram with an odd value first and restart for every run, but
> the rtos or allocator may have this data accessable anyway. Then, just
> put more and more load on the system until you get the info you need.

<frown>  You need a good understanding of the system to know
what *kind* of load is needed.  I.e., understand it which conditions
demands on memory are greatest.  You also need to understand how
that memory is being *used*.  E.g., my systems will tend to "hunt"
for the maximum memory usage point -- deliberately consuming as
many resources as the system has been endowed with to improve
performance/efficiency/responsiveness/etc. (within constraints
set out at design time).  So, in my case, the answer to the
"how much memory does it need" question is:  "all of it"
(else you are paying for a resource that you don't need  :> )

> Even the smallest system can benefit from a syslog() type facility that
> is designed in from the start, showing what the system is doing while
> running and typically only needs 10's of lines of code to implement on a
> simple system...

+1

Implement a black box in a portion of "unused" RAM, Flash, etc.
This helps with post mortems.  Note that it can be a "rich"
interface (e.g., text messages, etc.) or a crude one (e.g.,
timestamp plus unique "situation code") that must be
postprocessed to extract meaningful information.

During development, you can wire your DEBUG() to a stub that
pushed characters out on your development system console.
If carefully designed, you can share this "device" among
multiple threads so each can tell the developer what it is
doing (I used ANSI3.64 escape sequences to set the *color*
of the text on a per thread basis so it was easier to
follow what each task was saying)
    "SysInit: Creating task B at 0x34005000"
    "Task A: waiting for event 0x23"
    "SysInit: Allocating 0x4000 stack for task B"
    "Task D: raising 0x23"
    "Task A: caught 0x23"
    "SysInit: Starting task B"
    "Task B: Why is there air?"
    "Bill Cosby:  To blow up basketballs!"

You can also put conditionals in the various DEBUG()'s
to enable or disable, selectively, output (and quantity
of output -- "debug level") from various tasks.

And, when you're ready to ship the product, recompile
with:

#define DEBUG()

and you're ready to go!