The $55 trick is great for stack estimations - but it won't show the current
malloc usage ... unless you refill the used areas with $55 each time they
are free()d.
You will simply see the places where malloc has not been. If you malloc then
free a block repeatedly, the allocator might "walk" over the full pool
space, even though only one chunk is currently being used ... depends on the
malloc algorithm.
A simple "malloc current used" integer being moved up by N for every
successful malloc and decreased by N every sucessful free will allow you to
track malloc usage.
Also if you set a "max used" variable each time the "total used" variable
goes up then you will be able to see the peak pool as well as the current
pool usage.
This will require a customised malloc & free for testing - but the size and
speed hit is negligible.
[In the past I have used custom versions of malloc, free, memcpy etc to
check for many possible problems such as stupidly long move counts, zero
move counts, target addresses outside RAM space, source address outside RAM
and ROM space etc. You can find some really strange killer coding errors
doing this sort of thing]
Richard
----- Original Message -----
From: "Neil Wyper" <nwy...@gmail.com>
To: <mspgcc-users@lists.sourceforge.net>
Sent: Wednesday, December 21, 2005 3:37 PM
Subject: Re: [Mspgcc-users] Memory usage on the target
If you are using malloc, you can estimate how much memory is used fairly
easily:
1. At the beginning of the startup code (before idata and bss are set up),
fill all ram with an arbitrary value, like 0x55.
2. Let your application run for a long time
3. Examine the contents of memory looking for contiguous blocks of 0x55.
The block between the stack and the heap is the only one that is very
interesting, as any other blocks are likely uninitialized arrays and
unused
blocks from the heap. This block represents all of the ram that has not
been
used, yet.
This only gives an estimate, because if you're using malloc, you probably
won't be able to determine if more blocks will be taken from the heap
later.
Increasing the time the system runs before examining your ram contents
will
improve confidence in the estimate. Even without malloc, this can show
you
the maximum stack usage at any time.
It's not perfect, but you can leave the ram initialisation in your startup
code forever, and always have a way of checking the ram contents against a
known initial value. Also, using a strange value (not 0x00 or 0xFF) can
make
bugs involving uninitialised memory more obvious.
Neil
On Wednesday 21 December 2005 01:12, nobo...@web.de wrote:
Hi,
the msp430-size can't estimate how much space will be used on the stack
and on the heap.
The only way is to use a stackcheck (see at examples) and not use
malloc.
Regards,
Rolf
mspgcc-users@lists.sourceforge.net schrieb am 21.12.05 08:30:07:
> msp430-size <file-name>.elf
>
> Sincerely,
>
> David Smead
> www.amplepower.com
> www.amplepower.net
>
> On Wed, 21 Dec 2005, Thomas - DC2RPT wrote:
> > Hi,
> >
> > Maybe someone could help me a little bit.
> >
> > - Is it possible to find out in a easy way, how much of my ram (not
> > flash) on the target is used or how could i see at least, if i use to
> > much ?
> >
> > cu Thomas
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > log
> > files for problems? Stop! Download the new AJAX search engine that
> > makes searching your log files as easy as surfing the web. DOWNLOAD
> > SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Mspgcc-users mailing list
> > Mspgcc-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log
> files for problems? Stop! Download the new AJAX search engine that
> makes searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files for problems? Stop! Download the new AJAX search engine that
makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
