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!

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

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.

[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, ...]

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.

Sounds interesting! I may give your product a try. Thank you.

On Mar 11, 2:10=A0am, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:
> Tim Wescott wrote:
> > On Thu, 10 Mar 2011 20:23:36 -0800, 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 th=
e
> >> 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?
>
> > ...
> > If you're not using the heap, then the next problem down is stack space=
. =A0
> > I _think_ there are tools that estimate this, but all I've ever done is
> > fill the stack with 0xf00d or 0xdeadbeef or whatever, and look for the
> > high water mark.
>
> Some compilers can tell you the stack size for each function, and
> perhaps even for a whole call tree. GCC has the option -fstack-usage.
> The IAR compiler may have such an option, too.
>
> There are also tools that use static analysis of the machine code to
> compute an upper bound on stack usage, for example Bound-T (from my
> company),www.bound-t.com, or the other tools listed athttp://www.bound-t.=
com/stack-usage-tools.html. But these tools only
> support certain processors, and (like the compiler-given stack sizes)
> can fail if the program is recursive or allocates stack space in very
> dynamic ways, for example with the alloca function.
>
> You say that too little SDRAM may "affect the performance". This
> suggests that your program uses heap memory heavily and dynamically, or
> that you have a virtual-memory machine with a backing store (swap
> device). There has been research on static analysis to compute bounds on
> heap usage, but I don't know of any available tools for that. If the
> program itself adjusts its heap usage to fit the available memory, I
> don't think any general static analysis could tell you how much memory
> is needed for "good" performance.
>
> HTH
>
> --
> Niklas Holsti
> Tidorum Ltd
> niklas holsti tidorum fi
> =A0 =A0 =A0 =A0. =A0 =A0 =A0@ =A0 =A0 =A0 .- Hide quoted text -
>
> - Show quoted text -

Sounds good to me. I will give it a shot.

On Mar 11, 9:44=A0am, Chris H <ch...@phaedsys.org> wrote:
> In message <3d3001b1-1013-4bf1-b419-aa2eafe7d...@r4g2000prm.googlegroups
> .com>, Like2Learn <like2le...@live.ca> writes
>
> >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.
>
> Load the IAR compiler. =A0They usually come complete with C-spy
> debugger/simulator. =A0 That will give you all the answers you need along
> with the map file.
>
> Which target is it for?
>
> --
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills =A0Staffs =A0England =A0 =A0 /\/\/\/\/
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

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


On Mar 11, 12:02=A0am, D Yuniskis <not.going.to...@seen.com> wrote:
> On 3/10/2011 9:23 PM, 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?
>
> Since it is a "legacy embedded product", it already exists and is
> (or was) in production. =A0Why not look at the bill of materials and
> see how much physical memory it *had* previously?

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.

On Mar 10, 10:48=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Thu, 10 Mar 2011 20:23:36 -0800, 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?
>
> A good part of the total should be statically allocated memory. =A0For th=
at
> you can just look at the map file -- it should spell out how much memory
> is used.
>
> If you're not using the heap, then the next problem down is stack space. =
=A0
> I _think_ there are tools that estimate this, but all I've ever done is
> fill the stack with 0xf00d or 0xdeadbeef or whatever, and look for the
> high water mark.
>
> If you are using the heap but only to allocate at startup, then you need
> to use a heap manager that's instrumented. =A0Look around -- everyone and
> their brother has written a 'malloc' at some point in their lives, some
> of them are even instrumented.
>
> If you are using the heap, and you're not just using it to allocate
> memory at startup and never deallocate it, then you're eventually going
> to kill the app from heap fragmentation anyway, so there's no point in
> measuring.
>
> --http://www.wescottdesign.com

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. 
  Your bad if the legacy code base wasn't stored along with the original 
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_.  The only static 
analysis tool that will reliably reproduce the memory allocations of an 
actual compiler and linker are that same compiler and linker.