AVR Freaks

Tools, Compilers and General Programming

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

Posted by schickb: Wed. May 27, 2009 - 10:40 PM

I am considering putting together a free online tool for map file analysis. Something that accepted a gcc linker mapfile and showed a sortable data table and with a bar chart that lets you quickly see function sizes and addresses.

A few questions:

- Does something like this exist already? I didn't find anything after a quick search.
- Would people find this useful?
- I'd probably use yahoo's datatable an chart tools which are based on flash. Is that a major barrier?

Any other ideas for what the tool might show? For simplicity I don't think it would store any of the uploaded info, it would just parse the mapefile and show the results.

-Brad

Tags:

abcminiuser

Level: Raving Lunatic

Joined: Fri. Jan 23, 2004

Posts: 9856 View posts

Location: Melbourne, Australia

Posted by abcminiuser: Wed. May 27, 2009 - 11:04 PM

For the size of functions, you can just do a:

avr-nm --size-sort YourProject.elf

Which gives a sorted (ascending) list of all data/functions in your app from smallest to largest. It uses the GCC symbol identifiers for each one (e.g. "T" is a FLASH function symbol, normal strength) which you can convert to something more readable with sed/awk.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

Posted by schickb: Wed. May 27, 2009 - 11:09 PM

abcminiuser wrote:

For the size of functions, you can just do a:

avr-nm --size-sort YourProject.elf

I know its possible to get the data yourself in various ways. Should I take it that your response means it is easy enough that an online tool with a graph wouldn't really be that useful? Or are you just saying using avr-nm on elf files would be a good way to build the tool rather than map file analysis?

-Brad

atomicdog

Level: Posting Freak

Joined: Mon. Jan 14, 2008

Posts: 1172 View posts

Location: San Diego

Posted by atomicdog: Thu. May 28, 2009 - 03:30 AM

The map file is easy enough to understand but it would be nice to have something that was more 'pleasant' to read. It would also make it easier to find what you're looking for.

~~John
TWI C source code

Level: Raving Lunatic

Joined: Fri. Dec 20, 2002

Posts: 7524 View posts

Location: Dresden, Germany

Posted by dl8dtl: Thu. May 28, 2009 - 06:51 AM

> The map file is easy enough to understand

I never found it anything like easy to understand. To me, it looks
more like a debugging aid for GNU ld developers, and/or for linker
script writers.

> but it would be nice to have something that was more 'pleasant' to read.

That's what IMHO the symbol table is good for, i.e. the output from avr-nm,
with a variety of possible options (including the one Dean mentioned, though
I'd personally add -S aka. --print-size as well).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Thu. May 28, 2009 - 09:27 AM

Brad,

You do know that the Mfile template Makefile generates a project.sym as well as a project.map don't you? What do you have in mind that the .sym file doesn't already offer?

(though it's true that, like Dean, I find avr-nm with the --size-sort useful from time to time - especially when you are just over a "size border" as it's the big functions that probably have the most room for hand optimised improvemens)

Cliff

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

Posted by schickb: Thu. May 28, 2009 - 07:22 PM

clawson wrote:

You do know that the Mfile template Makefile generates a project.sym as well as a project.map don't you? What do you have in mind that the .sym file doesn't already offer?

A graphical easily sortable presentation of all that information.

But it seems like there isn't too much interest in that, so I probably won't do it.

-Brad

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

Posted by wek: Thu. May 28, 2009 - 09:37 PM

schickb wrote:

Should I take it that your response means it is easy enough that an online tool with a graph wouldn't really be that useful?

What kind of graph do you have on mind? I can't quite visualise it.
Could you quickly hand-sketch an example and post it here?

http://www.mikroe.com/en/compile...

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

Posted by schickb: Thu. May 28, 2009 - 09:46 PM

wek wrote:

schickb wrote:
Should I take it that your response means it is easy enough that an online tool with a graph wouldn't really be that useful?

What kind of graph do you have on mind? I can't quite visualise it.
Could you quickly hand-sketch an example and post it here?

The idea came from the mikroC Pro compiler announcement on the AVRFreaks main page, so they would probably be similar. Scroll to the "Statistics" section about halfway down this page:

For example:
http://www.mikroe.com/en/compile...
http://www.mikroe.com/en/compile...

-Brad

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#10

Posted by wek: Thu. May 28, 2009 - 09:58 PM

Of the many, only http://www.mikroe.com/en/compile... appears to me to easier provide information at a glance than what's available now in the various ouput files. Thus this would be fine to have. Plus a similar one for RAM usage (although that might get even more tricky).

However, might be tricky to implement so that it will display legible/reasonable/relevant information with all sizes of programs (from 1-function to 10000-function) and all sizes of memories, and all sizes of displays. Mind that legibility decreases with density of information and with need for scroll.

But this all appears to be dependent on personal taste, so prepare yourself for quite a bit of controversy.

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

#11

Posted by schickb: Fri. May 29, 2009 - 04:53 AM

wek wrote:

However, might be tricky to implement so that it will display legible/reasonable/relevant information with all sizes of programs (from 1-function to 10000-function) and all sizes of memories, and all sizes of displays.

That's easy to solve, just provide an option to limit the number of symbols displayed. Combined with sorting, you'd get decent good control of the display.

But its really a mute point, since there hasn't been enough interest to bother. That's ok... more time for other stuff ;)

-Brad

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#12

Posted by clawson: Fri. May 29, 2009 - 10:41 AM

Quote:

The idea came from the mikroC Pro compiler announcement on the AVRFreaks main page, so they would probably be similar. Scroll to the "Statistics" section about halfway down this page:

Pretty pictures yes, but I can "see" the same in:

D:\sounds\avrapp>avr-nm --size-sort sounds.elf
...

...
000000f0 T dflash_start_write_active
000000fa T __vector_1
0000010c T adpcm_decoder2
0000010e T adpcm_decoder1
00000110 T time_uart_bit0
00000116 T dump_ram
0000013c T dflash_flush_buffer
0000014a T adpcm_coder
00000214 T main
0000021c T transmit_flash
00000230 T __vector_8
000002d2 T dump_vars
00000318 T my_spm_routine
00000324 T dump_flash
0000032e T help
0000037c T motor_test
00000498 T play_flash

which is an ascending list of routine sizes - sure there's no bar graphs but I guess I could script something to output an increasing number of asterisks if really moved to.

(clearly if I was looking for space savings I'd start with play_flash() )

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#13

Posted by wek: Fri. May 29, 2009 - 11:13 AM

clawson wrote:

I guess I could script something to output an increasing number of asterisks if really moved to.

Yeah - the *nix notion of nice graphics... ;-)

timojaask

Level: Wannabe

Joined: Thu. Nov 13, 2008

Posts: 88 View posts

Location: Turku, Finland

#14

Posted by timojaask: Fri. May 29, 2009 - 12:02 PM

I think that's a nice idea. If you think you wanna do it - do it. Experimenting with stuff is fun :D
Though, I would personally find it more useful to have a tutorial on this stuff, like understanding map files, linker scripts and so on.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#15

Posted by clawson: Fri. May 29, 2009 - 12:17 PM

Quote:

The idea came from the mikroC Pro compiler announcement on the AVRFreaks main page,

BTW I can't help thinking they might do better to putting their development effort into making the core of their C compiler work rather than adding "eye candy". But that seems to be the MikroE approach to life.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#16

Posted by wek: Fri. May 29, 2009 - 01:21 PM

clawson wrote:

Quote:

The idea came from the mikroC Pro compiler announcement on the AVRFreaks main page,

BTW I can't help thinking they might do better to putting their development effort into making the core of their C compiler work rather than adding "eye candy". But that seems to be the MikroE approach to life.

Why?

Does their compiler have any serious defficiencies? Any experiences? (not trolling, just curious)

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#17

Posted by clawson: Fri. May 29, 2009 - 01:45 PM

JW,

I'll see if I can find it - they made an announcement in AVR Forum when it was in beta. A lot of the "locals" downloaded, I don't think anyone was impressed and a number of serious deficiencies were found. It seems like they are more interested in selling a "complete package" of dev kit, programmer and build tools targetted at only working with their system with no hint of standard compliance or anything.

Cliff

EDIT: found it https://www.avrfreaks.net/index.p...

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

#18

Posted by schickb: Fri. May 29, 2009 - 06:47 PM

clawson wrote:

sure there's no bar graphs but I guess I could script something to output an increasing number of asterisks if really moved to.

I wonder if the Chinese proverb "A picture is worth a thousand words" had asterisks in mind ;)

-Brad

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#19

Posted by skeeve: Fri. May 29, 2009 - 07:01 PM

schickb wrote:

clawson wrote:
sure there's no bar graphs but I guess I could script something to output an increasing number of asterisks if really moved to.

I wonder if the Chinese proverb "A picture is worth a thousand words" had asterisks in mind ;)

It a lot of cases, it wouldn't matter.
The data being represented would be less than a thousand words.

Something that might be useful is partial sum information, e.g.:

size   sum symbol
1234  1234  fred
1111  2345  greg
 234  2579  hank
  12  2591  ivan

It's hard to feed a graph to another program.

Iluvatar is the better part of Valar.

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

#20

Posted by schickb: Fri. May 29, 2009 - 07:29 PM

skeeve wrote:

It's hard to feed a graph to another program.

I don't want to start a huge debate, but that's a fairly pointless statement in this context. Even if true, that statement doesn't diminish the usefulness of graphs as a way to visualize data. Of course it would be bad if a graph was the only output of avr-nm or something, but since that isn't the case we don't have much to worry about by *adding* graphs on top of parseable data.

Now, no one may actually have a need for the graphs given the existing text representations, but that's a different argument.

-Brad

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#21

Posted by wek: Fri. May 29, 2009 - 08:13 PM

clawson wrote:

found it https://www.avrfreaks.net/index.p...

Thanks, Cliff.

A hour+ of reading... Well, from what I can read in that thread, it's not THAT bad, given a bunch of reviewers with strong opinions, and an immature beta product with code size limitations... ;-)

I have heard praises on their PIC Pascal which AFAIK is their original product, but given the present situation, if the guys won't die from hunger, they simply must try to make it on the "majority" market, too. There also the roots of their business model.

The website is far the nicest among the competitors, too. It does not appeal to me personally, but in 21st century it is certainly a factor to count.

Thanks again for the link.

Jan

PS. Sorry for hijacking the thread. Oh, and if we vote, I think I already said yes for the sizes graph, no asterisks ;-)

ArnoldB

Level: Raving Lunatic

Joined: Thu. Nov 29, 2007

Posts: 3188 View posts

#22

Posted by ArnoldB: Fri. May 29, 2009 - 08:27 PM

clawson wrote:

sure there's no bar graphs but I guess I could script something to output an increasing number of asterisks if really moved to.

Indeed a piece of cake.

#!/bin/sh
nm --demangle --size-sort "$@" | awk -v WIDTH=`tput cols` '

BEGIN {
	if(N == 0)
		N = 20	# Nbr of largest symbols we are interested in
	if(WIDTH == 0)
		WIDTH = 80
	if(C == "")
		C = "*"
	n = 0
}

#
# Grep text (code) symbols only).
# TODO: Other symbols might be of interest, too.
#
$2 == "T" {
	l[n++ % N] = $0	# Buffer last/largest N lines only
}

function stars(n)
{
	while(n-- > 0) {
		printf C
	}
}

function println(ndx, max,	size, sym)
{
	$0 = l[ndx]
	sym = $3
	size = strtonum("0x" $1)
	printf sym " "
	stars(WIDTH / max * size - length(sym) - 2)
	print ""
}

END {
	end = n % N
	size = n > N ? N : end
	$0 = l[end - 1]
	max = strtonum("0x" $1)
	if(max <= 0) {
		print "No data."
		exit 1
	}
	for(i = end; i < size; i++) { println(i, max) }
	for(i = 0; i < end; i++)    { println(i, max) }
}
'

Stealing Proteus doesn't make you an engineer.

ArnoldB

Level: Raving Lunatic

Joined: Thu. Nov 29, 2007

Posts: 3188 View posts

#23

Posted by ArnoldB: Fri. May 29, 2009 - 08:33 PM

wek wrote:

clawson wrote:
I guess I could script something to output an increasing number of asterisks if really moved to.

Yeah - the *nix notion of nice graphics... ;-)

You know how one can identify GUI zealots? They put the form ("it must be a GUI, whine, whine whine") before the information, and thereby entirely missing the point of the information.

Stealing Proteus doesn't make you an engineer.

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#24

Posted by skeeve: Fri. May 29, 2009 - 08:42 PM

schickb wrote:

skeeve wrote:
It's hard to feed a graph to another program.

I don't want to start a huge debate, but that's a fairly pointless statement in this context. Even if true, that statement doesn't diminish the usefulness of graphs as a way to visualize data. Of course it would be bad if a graph was the only output of avr-nm or something, but since that isn't the case we don't have much to worry about by *adding* graphs on top of parseable data.

Now, no one may actually have a need for the graphs given the existing text representations, but that's a different argument.

In the case at hand,
I'm don't see that a graph would add all that much.
Another dimension might change that,
possibly size vs. something else.

Iluvatar is the better part of Valar.

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

#25

Posted by schickb: Fri. May 29, 2009 - 08:43 PM

ArnoldB wrote:

You know how one can identify GUI zealots? They put the form ("it must be a GUI, whine, whine whine") before the information, and thereby entirely missing the point of the information.

I guess I shouldn't be taking the flame bait, but personally I am a Linux terminal user for most of my dev work. So I'm not even GUI fan, let alone a zealot.

But I'm not so fullish to believe there is no use for graphical presentations of data... even if this isn't one of them.

-Brad

Level: Raving Lunatic

Joined: Thu. Mar 1, 2001

Posts: 4934 View posts

Location: Rocky Mountains

#26

Posted by EW: Mon. Jun 1, 2009 - 10:43 PM

I see nothing wrong with having both approaches. Zealotry comes into play when one side is picked exclusively over the other.

There are some tools that can make graphics based on text input only. They're used in building a few of the graphics in the avr-libc user manual. I'm not terribly familiar with how they work, but I'm wondering if the output of avr-nm can be fed into those tools and a nice graph could be automatically built. If so, then it could be easily added as an additional build step in the Makefile.

Eric Weddington
www.linkedin.com/in/ericweddington/

Level: Raving Lunatic

Joined: Thu. Mar 1, 2001

Posts: 4934 View posts

Location: Rocky Mountains

#27

Posted by EW: Tue. Jun 2, 2009 - 08:09 PM

In doing some research, it looks like there should be a way to build complex graphs from existing data using gnuplot (http://www.gnuplot.info/) and some post-compilation processing, either in a separate shell script, or perhaps in the Makefile itself. gnuplot is available on Cygwin, so this can be done also on Windows machines.

Anyone want to try to come up with a script that can generate these graphs using gnuplot?

Eric Weddington
www.linkedin.com/in/ericweddington/

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#28

Posted by clawson: Wed. Jun 3, 2009 - 12:01 PM

Eric,

I downloaded Gnuplot and looked at the demos and also had a flick through the manual but the whole thing seems a bit "heavy" for such a simple job - the tar.gz is 2.5MB apart from anything else. I'll have a hunt round and see if I can find a simpler data->JPG (or similar utility) with open source. Failing that it must be fairly easy to do something with libjpeg and some rectangle drawing routines (the trickiest bit is probably rendering text onto the jpeg in a platform independent way)

Cliff

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#29

Posted by wek: Wed. Jun 3, 2009 - 12:38 PM

clawson wrote:

I downloaded Gnuplot and looked at the demos and also had a flick through the manual but the whole thing seems a bit "heavy" for such a simple job - the tar.gz is 2.5MB apart from anything else.

I am messing with it, too, between lengthy compiles, and don't like it either. It's certainly a fine thing for what it's intended for - drawing x-y graphs.

I'll investigate this further, meantime, a small taster of what can be achieved (this is cca 1/3 of my program's code).

Attachment(s):

a.png

Last Edited: Wed. Jun 3, 2009 - 12:42 PM

http://dsrg.mff.cuni.cz/~ceres/p...

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#30

Posted by clawson: Wed. Jun 3, 2009 - 12:41 PM

I came across "Bagatel" on this page:

which is open source and looks like it could probably be built for Linux and Windows (I think)

I'll see if I can get it building in Cygwin to get a Win32 version (I'm assuming there'd be no problem building it in Linux!)

The kind of graphs it generates can be seen (for example) here:

http://dsrg.mff.cuni.cz/~ceres/p...

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#31

Posted by skeeve: Wed. Jun 3, 2009 - 01:08 PM

For the diagrams in my thesis, I generated encapsulated postscript directly.

Iluvatar is the better part of Valar.

Perl/GD script (had to zip it since .pl is not an allowed suffix :-( )

Level: Raving Lunatic

Joined: Fri. Dec 20, 2002

Posts: 7524 View posts

Location: Dresden, Germany

#32

Posted by dl8dtl: Wed. Jun 3, 2009 - 01:51 PM

I've hacked a Perl script (using GD), just if someone wants to give
it a try...

The attached graph (taken from a larger project) also shows the limited
usefulness of the result...

Attachment(s):

Sample graph

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#33

Posted by clawson: Wed. Jun 3, 2009 - 02:05 PM

JÃ¶rg,

The only argument against that is that Windows does not natively support Perl and a typical distribution (ActivePerl: http://www.activestate.com/activ... ) is a 17MB download so that's going to bloat WinAVR quite a bit!

When hunting around I also found a Python based solution which looked great until I found it would need the ~300MB download of Python for Windows.

Just blitting some pixels for graph and text labels into a frame buffer then writing this to BMP, PNG, GIF or JPG shouldn't need megabytes of software to achieve. I'm kind of surprised it's proving so difficult to find someone who has previously put together a simple solution for this.

Level: Raving Lunatic

Joined: Fri. Dec 20, 2002

Posts: 7524 View posts

Location: Dresden, Germany

#34

Posted by dl8dtl: Wed. Jun 3, 2009 - 03:17 PM

> I'm kind of surprised it's proving so difficult to find
> someone who has previously put together a simple solution for this.

Well, for most Unices, things like Perl or Python are usually around alraedy
anyway... so it's not a big deal to use these scripting languages there.
Windows simply has a different set of tools.

I think, if at all, it would probably be better done with some kind of
interactive tool, so you could e.g. provide "tooltip" information when
moving the cursor over some block. Also, this would allow for a scrollbar
on the Y direction. However, hacking something like that was simply beyond
the time I've had available for this.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#35

Posted by wek: Wed. Jun 3, 2009 - 03:30 PM

dl8dtl wrote:

> I'm kind of surprised it's proving so difficult to find
> someone who has previously put together a simple solution for this.

Well, for most Unices, things like Perl or Python are usually around alraedy
anyway... so it's not a big deal to use these scripting languages there.

This is again a traditinal view.

With the present invent of "boxed" Linux distros like Ubuntu intended primarily for mere users rather than cool *nix gurus, the development tools start to miss by default (OK interpreters like Perl and Python and Java may continue to be present, but gcc and kin is typically not installed by default).

PS. Actually... when I get home I'll check on my tiny Eee70x for perl and python.

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#36

Posted by skeeve: Wed. Jun 3, 2009 - 04:00 PM

dl8dtl wrote:

> I'm kind of surprised it's proving so difficult to find
> someone who has previously put together a simple solution for this.

Well, for most Unices, things like Perl or Python are usually around alraedy
anyway... so it's not a big deal to use these scripting languages there.
Windows simply has a different set of tools.

What diagram-generating tools does Windows usually have?

Iluvatar is the better part of Valar.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#37

Posted by clawson: Wed. Jun 3, 2009 - 04:11 PM

Quote:

What diagram-generating tools does Windows usually have?

Paintbrush

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#38

Posted by skeeve: Wed. Jun 3, 2009 - 04:37 PM

clawson wrote:

Quote:

What diagram-generating tools does Windows usually have?

Paintbrush

Does it take text input?

Iluvatar is the better part of Valar.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#39

Posted by wek: Wed. Jun 3, 2009 - 04:43 PM

skeeve wrote:

clawson wrote:
Quote:

What diagram-generating tools does Windows usually have?

Paintbrush
Does it take text input?

Sure. After a few mouse-clicks, you can use it as a typewriter. :-P

PS. OK, and what diagram-generating tool do *nices usually have?

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#40

Posted by clawson: Wed. Jun 3, 2009 - 04:44 PM

Not really it's a paint program - sure there's a dialog where you can enter text that will be rendered onto the image but this cannot be script/command line driven.

Level: Hangaround

Joined: Mon. May 7, 2007

Posts: 291 View posts

Location: Seattle

#41

Posted by schickb: Wed. Jun 3, 2009 - 05:05 PM

dl8dtl wrote:

I think, if at all, it would probably be better done with some kind of
interactive tool, so you could e.g. provide "tooltip" information when
moving the cursor over some block. Also, this would allow for a scrollbar
on the Y direction. However, hacking something like that was simply beyond
the time I've had available for this.

That is why my original idea was to do this online with a free flash based graphing tool from Yahoo. It would provide interactive on the fly sorting, tool tips, and results limiting (so you could view just the top N results).

-Brad

Level: Raving Lunatic

Joined: Sun. Oct 29, 2006

Posts: 5071 View posts

#42

Posted by skeeve: Wed. Jun 3, 2009 - 05:18 PM

wek wrote:

PS. OK, and what diagram-generating tool do *nices usually have?

Tk can be used from Tcl and python.
The canvas widget has a postscript method that will (duh) generate a postscript representation.
For my thesis diagrams, I generated encapsulated postscript directly.
pstopnm can convert postscript to raster scan.
pnmtowhatever can convert pnm to rather a lot of things.

I'm pretty sure that python and Tk are ordinary.
I'm not sure about the pnm tools.
Tk is designed to show stuff.
There might be a way to generate postscript
without showing a canvas on the screen,
but I don't know it.

Iluvatar is the better part of Valar.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#43

Posted by wek: Wed. Jun 3, 2009 - 05:23 PM

skeeve wrote:

wek wrote:
PS. OK, and what diagram-generating tool do *nices usually have?
Tk can be used from Tcl and python.
The canvas widget has a postscript method that will (duh) generate a postscript representation.
For my thesis diagrams, I generated encapsulated postscript directly.
pstopnm can convert postscript to raster scan.
pnmtowhatever can convert pnm to rather a lot of things.

I'm pretty sure that python and Tk are ordinary.
I'm not sure about the pnm tools.
Tk is designed to show stuff.
There might be a way to generate postscript
without showing a canvas on the screen,
but I don't know it.

Well, I'd bet, few to none of the listed (ps_to_whatever, tcl/tk, python) is available on the "boxed" linuces I mentioned above, so these are none better than anything what needs to be installed on Win, either.

The 2MB+ of that gnuplot thingy sounds like a bargain in this respect.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#44

Posted by clawson: Wed. Jun 3, 2009 - 05:25 PM

Brad / Michael / JW,

If this was done you need to bear in mind that the solution needs to work (or at least should be buildable) on both Windows and Linux platforms and that it cannot rely on a huge support library (like Python) that would bloat a delivery such as WinAVR for a tool that most people probably don't want or care about.

I just started writing something in plain C which will even include 8x8 (possibly larger?) font definitons and render onto a 24-bit BMP file (the world's easiest to create graphic file format?).

So far the standalone Windows .exe is 28KB. What I don't propose to do is try to display this - all desktop systems have SOME way to view .BMP files. This does mean that there won't be a cursor and tooltips etc. Just a picture like the one on the Mikroe site:

(that doesn't appear to offer interactivity - just a fixed image)

Cliff

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#45

Posted by wek: Wed. Jun 3, 2009 - 05:35 PM

clawson wrote:

I just started writing something in plain C which will even include 8x8 (possibly larger?) font definitons and render onto a 24-bit BMP file (the world's easiest to create graphic file format?).

Very well.

Do you intend to input the nm format, i.e. "position size something name"?

I would offer to make a few changes the simplistic tool I made recently, to output a similar list. It opens possibilites nm can not have, e.g. filtering by sub-sections (ever wondered about usage of .progmem section?)

Just that it's Pascal (primarily FreePascal, so with nil to little effort can be built on Linux or whatever), so it's been most probably frowned upon here... :-|

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#46

Posted by clawson: Wed. Jun 3, 2009 - 05:43 PM

Quote:

Do you intend to input the nm format, i.e. "position size something name"?

Like Joerg's Perl script I was just going to take the output of "avr-nm --size-sort -t decimal file.elf" and process that. I guess I could just take the "file.elf" and spawn() that avr-nm command to keep it "inside" but maybe it can be more generic and just graph anything with numbers at the start of a line followed by some text? In which case I'd just use it in a pipe'd command line.

Level: Raving Lunatic

Joined: Fri. Dec 20, 2002

Posts: 7524 View posts

Location: Dresden, Germany

#47

Posted by dl8dtl: Wed. Jun 3, 2009 - 06:09 PM

If you write it in C, you could probably even (dynamically?) link against
libbfd.a (part of binutils, which is part of WinAVR anyway) to read the
ELF file directly. That might be easier than parsing the output of another
tool.

All the c.NNNN labels in my output are supposedly module-internal ("static")
functions. Their actual names could be resolved through debugging symbols
(I believe).

The tricky thing with using plain C is that plain C doesn't offer graphics,
and using some platform-independant graphics option will get you
back to where you came from... By now, the only related stuff that's
already part of WinAVR would be Tcl/Tk (that's why I wrote Mfile
using that toolkit).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3271 View posts

Location: Bratislava, Slovakia

#48

Posted by wek: Wed. Jun 3, 2009 - 06:35 PM

dl8dtl wrote:

If you write it in C, you could probably even (dynamically?) link against
libbfd.a (part of binutils, which is part of WinAVR anyway) to read the
ELF file directly. That might be easier than parsing the output of another
tool.

Maybe, but it then certainly loses a great degree of flexibility.

If it inputs a position-size-name list, in an unix-like chain of utilities could be reused for other purposes - e.g. to display similar graph for SDCC (which can't produce elf at the moment).

On the other hand, the tool producing the list can then be easily recreated with different toolset, with different properties, etc.

dl8dtl wrote:

All the c.NNNN labels in my output are supposedly module-internal ("static")
functions.

No - all static functions are output with their true name, with lowercase "t" as the "flag". The "c.whatever" are actually the result of using the PSTR macro; those are static data arrays, all declared with name "c".

Note, that nm has no way of telling, in which input (sub-)section the "function" was, so you can't distinguish .progmem* (constants) from "genuine" functions (both are .text output section) - this information is lost during linking and is not present in .elf. You should also go into the pains of go through the debug info to match symbols to their respective sources. In this regard, the link map is superior source of information - and it would be so generally, wouldn't the linker simply omit ALL the static symbols from the mapfile...

This could be one more reason to keep the data preparation and the graph drawing separate.

ArnoldB

Level: Raving Lunatic

Joined: Thu. Nov 29, 2007

Posts: 3188 View posts

#49

Posted by ArnoldB: Wed. Jun 3, 2009 - 07:02 PM

Window's standard diagram generating tool in the bean counter category is called Excel - standard as far as paying extra for the privilege to mangle innocent number in unexpected ways is required.

As for all the diagram demos, well, well, well ... Nice demonstration of what I previously wrote.

So now, why not first select a diagram type that shows "something"? Like for example, to show how much of the flash is eaten by the largest functions in relation to the total used flash?

That would, for example, call for a pie chart. To avoid cluttering the chart I would go through the data to select the methods which together accumulate, let's say, 75% of the total used flash, but not more than, let's say, 15 functions. Whatever comes first when looking for the functions using 75%. All the rest would just be added up under the heading "others".

Doing it is left as an exercise to those who want a diagram. Hint: gnuplot can't do pie charts. GD can.

Stealing Proteus doesn't make you an engineer.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 97577 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#50

Posted by clawson: Wed. Jun 3, 2009 - 07:07 PM

(percent's in the following changed to '#' to protect the innocent)

Can I just stop to ask a beginners C question? If I do this I get the following output:

D:\c\makebmp>avr-nm --size-sort -t decimal \sounds\avrapp\timer1.o
00000018 r __c.2127
00000046 T time_uart_bit
00000102 T __vector_19
00000146 T set_baud_time
00000250 T __vector_1
00000272 T time_uart_bit0
00000560 T __vector_8

If I then use this C code:

int main(void) {
	FILE * fout;
	int i = 0;
	char * p;
	char line[200];
	
	do {
		fgets(line, 199, stdin);
		printf("input #02u = #s", i, line);
		i++;
	} while(!feof(stdin));

and this command I get:

D:\c\makebmp>avr-nm --size-sort -t decimal \sounds\avrapp\timer1.o | makebmp
input 00 = 00000018 r __c.2127
input 01 = 00000046 T time_uart_bit
input 02 = 00000102 T __vector_19
input 03 = 00000146 T set_baud_time
input 04 = 00000250 T __vector_1
input 05 = 00000272 T time_uart_bit0
input 06 = 00000560 T __vector_8
input 07 = 00000560 T __vector_8

What stupid beginner's error have I made here such that I read the last line twice?

Cliff