Map file analysis tool

Go To Last Post
102 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> 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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

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

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

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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() )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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... ;-)

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


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 ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

JW

Attachment(s): 

Last Edited: Wed. Jun 3, 2009 - 12:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I came across "Bagatel" on this page:

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

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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): 

Jörg Wunsch

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> 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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

JW

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What diagram-generating tools does Windows usually have?

Paintbrush

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

What diagram-generating tools does Windows usually have?

Paintbrush
Does it take text input?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

JW

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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... :-|

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Window's standard diagram generating tool in the bean counter
> category is called Excel

Ah well, if you count that, we could ship a copy of openoffice...
No need to complain about a couple of megabytes for a Perl or
Python distribution. ;-)

Jörg Wunsch

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

You didn't check feof before the printf. So when you're at EOF at
the beginning of the do...while loop, you don't read anything
within the last cycle, yet you're still printing the previous
buffer again.

Jörg Wunsch

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

You expected that feof() will work as normal people expect.

http://c-faq.com/stdio/feof.html

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jörg,

Thanks. So this is what I've come up with so far:

#include 

#define DEBUG_TEXT

// don't want to rely on windows.h so ...
#define WORD short 
#define SHORT short
#define DWORD int

// pixel width of whole image
#define OUT_WIDTH 768
#define OUT_WIDTH_FLOAT 768.0
// pixel width of the text labels
#define LABEL_WIDTH 100
#define LABEL_WIDTH_FLOAT 100.0
// pixel height of one line of output (8 for font + 2)
#define OUT_HEIGHT 10
// max number of input lines we'll consider
#define MAX_LINES 5000
// max characters on an input line
#define MAX_CHARS 200

extern unsigned char fontdata_8x8[];

typedef struct
{
	WORD   FileType;     /* File type, always 4D42h ("BM") */
	DWORD  FileSize;     /* Size of the file in bytes */
	WORD   Reserved1;    /* Always 0 */
	WORD   Reserved2;    /* Always 0 */
	DWORD  BitmapOffset; /* Starting position of image data in bytes */
} WINBMPFILEHEADER;

typedef struct 
{
	DWORD Size;            /* Size of this header in bytes */
	DWORD Width;           /* Image width in pixels */
	DWORD Height;          /* Image height in pixels */
	WORD  Planes;          /* Number of color planes */
	WORD  BitsPerPixel;    /* Number of bits per pixel */
} WIN2XBITMAPHEADER;

WINBMPFILEHEADER fileheader;
WIN2XBITMAPHEADER bitmapheader;

int lines_input;
int largest_size;
float xscale;
unsigned char * bitmap;

int main(void) {
	FILE * fout;
	int i = 0;
	char * p;
	char lines[MAX_LINES][MAX_CHARS]; // you gotta luv "big" OS's where this works ;-)
	int sizes[MAX_LINES];
	
	do {
		fgets(lines[i], MAX_CHARS-1, stdin);
		sizes[i] = atoi(lines[i]);
		if (sizes[i] > largest_size) {
			largest_size = sizes[i];
		}
		i++;
	} while(!feof(stdin) && i

When run this shows output such as:

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

largest = 560
scale = 1.19

and in the background creates a file called test.bmp which at the moment is the right dimension but all completely black because of:

	// the fun bit - render text and bars to 'bitmap' here

which I still need to fill in.

But I'll park that until tomorrow I think.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB wrote:
gnuplot can't do pie charts

I've just checked: gnuplot can do polar displays. With some effort, this can be used for pie charts.

But I'm sure Cliff's tool in version 0.4 can do pie charts, too.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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


That's why I was going to do it online as a hosted solution. Everyone has a browser. Although it would be nice to have a visual immediately after a build, I'm not sure it's going to be as useful without interactivity.

-Brad

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

That's why I was going to do it online as a hosted solution.

Ah Web 2.0 generation thinking eh? ;-)

(fine until your not in range of the internet)

By the way I'm kind of assuming that this would not be a standard option (say in the Mfile template) but an optional build option so the user would "make graphs" or something to get them generated. I'm not sure everyone would want heaps of graphic images being created on every build and, for sure, they wouldn't want to get dragged into some interactive GUI tool until requested.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I'm not sure everyone would want heaps of graphic images being created on every build

Well, if heaps of lists and maps and symbols files are created on every build, and nobody notices... Not that I disagree with what you said.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On one of my Ubuntu systems I installed a "boot profiler" that, on each boot, profiles where the milliseconds are being eaten and it's final output is a fairly large graph showing where the time was spent (in fact, as I mention it, maybe that has the tools for this job?). Anyway on a 4GB CompactFlash based system this started chewing it's way through the available space!

EDIT: the thing I'm thinking of is "apt-get bootchart" and the key component is bootchart.jar - so maybe forget that as an idea or can one rely on everyone having a JVM on both Linux and Windows?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Woo hoo! (little things please little minds) but here's the result of my first ever:

void render_char(int x, int y, unsigned char c) {
	unsigned char * p, rgb_val;
	int line, mask;
	int raster;
	
	p = (unsigned char *)((y * OUT_WIDTH * 3) + (x * 3) + bitmap);
	for (line = 0; line < 8; line++) {
		raster = fontdata_8x8[(c * 8) + line];
		for(mask=0x80; mask!=0; mask>>=1) {
			rgb_val = (raster & mask) ? 0x00 : 0xFF; // set black (0x00) if bit set
			*p++ = rgb_val; // B
			*p++ = rgb_val; // G
			*p++ = rgb_val; // R
		}
		p += ((OUT_WIDTH * 3) - (3 * 8)); // 3*8=24 bytes just set/reset
	}
}
...
	render_char( 10, 10, 'A');

(yup I know it's upside down - Windows is funny like that ;-))

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry if I sound like a kid with a new toy but..

(exe currently 45,506 bytes - a lot of that being debug and a font)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And then there was...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very nice.

But couldn't "type" (for the *nix types: cat) be used just for the same purpose, maybe more comfortably?
:-P

On the constructive side: "make graph" could use (repeatedly) Cliff'sTool(TM) to produce a set of .bmp files, a html file mentioning them all (including directly or as links), and then call the preferred browser - does this sound like a plan?

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A picture is worth a thousand words (you'll be pleased to hear). So here is a very rough finished output (still need to work on filling rectangles rather than drawing red/green/blue lines)...

(rather curiously it's still 45,506 bytes?)

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And here's the code that generated that:

/*
** Another Beerware prodction from Cliff Lawson
**
** Feel free to abuse this code in whatever way you see fit
*/
#include 

#define DEBUG_TEXT

// don't want to rely on windows.h so ...
#define WORD short 
#define SHORT short
#define DWORD int
// following is bmp compression format (none)
#define BI_RGB	0

#define BLACK	0x000000
#define RED 	0xFF0000
#define GREEN 	0x00FF00
#define BLUE	0x0000FF
#define WHITE	0xFFFFFF

// pixel width of whole image
#define OUT_WIDTH 768
#define OUT_WIDTH_FLOAT 768.0
// pixel width of the text labels
#define LABEL_WIDTH 250
#define LABEL_WIDTH_FLOAT 250.0
// pixel height of one line of output (8 for font + 2)
#define OUT_HEIGHT 10
// max number of input lines we'll consider
#define MAX_LINES 5000
// max characters on an input line
#define MAX_CHARS 200

extern unsigned char fontdata_8x8[];

typedef struct
{
	WORD   FileType;     /* File type, always 4D42h ("BM") */
	DWORD  FileSize;     /* Size of the file in bytes */
	WORD   Reserved1;    /* Always 0 */
	WORD   Reserved2;    /* Always 0 */
	DWORD  BitmapOffset; /* Starting position of image data in bytes */
} WINBMPFILEHEADER;

typedef struct 
{
	DWORD Size;            /* Size of this header in bytes */
	DWORD Width;           /* Image width in pixels */
	DWORD Height;          /* Image height in pixels */
	WORD  Planes;          /* Number of color planes */
	WORD  BitsPerPixel;    /* Number of bits per pixel */
	DWORD Compression;
	DWORD ImageSize;
	DWORD Hres;
	DWORD VRes;
	DWORD PalColors;
	DWORD ImportantColors;
} BITMAPINFOHEADER;

WINBMPFILEHEADER fileheader;
BITMAPINFOHEADER bitmapheader  = {
	40, 				// This Windows V3 header is always 40 bytes
	OUT_WIDTH, 			// fixed (768)
	0, 					// height will be calculated
	1, 					// RGB24 has just 1 plane
	24, 				//RGB24 (surprise, surprise) use 24 bits per pixel
	BI_RGB, 			// compression is "none"
	0, 					// ImageSize will be calculated
	0xB12,				// a sample file I created used this for "res" - so...
	0xB12,
	0,					// no palette so no colors
	0					// and none "important"
};

int lines_input;
int largest_size;
float xscale;
unsigned char * bitmap;
int bitmap_size;

void render_char(int x, int y, unsigned char c) {
	unsigned char * p, rgb_val;
	int line, mask;
	int raster;
	
	p = (unsigned char *)((y * OUT_WIDTH * 3) + (x * 3) + bitmap);
	for (line = 0; line < 8; line++) {
		raster = fontdata_8x8[(c * 8) + (7-line)];
		for(mask=0x80; mask!=0; mask>>=1) {
			rgb_val = (raster & mask) ? 0x00 : 0xFF; // set black (0x00) if bit set
			*p++ = rgb_val; // B
			*p++ = rgb_val; // G
			*p++ = rgb_val; // R
		}
		p += ((OUT_WIDTH * 3) - (3 * 8)); // 3*8=24 bytes just set/reset
	}
}

void render_string(int x, int y, char * str) {
	while(*str) {
		render_char(x, y, *str++);
		x += 8;
	}
}

void set_pixel(int x, int y, int colour) {
	unsigned char * p, rgb_val;
	int r,g,b;
	
	r = (colour & 0xFF0000) >> 16;
	g = (colour & 0x00FF00) >> 8;
	b = (colour & 0x0000FF);
	p = (unsigned char *)((y * OUT_WIDTH * 3) + (x * 3) + bitmap);
	*p++ = b;
	*p++ = g;
	*p++ = r;
}

void horiz_line(int x, int y, int colour, int len) {
	int i;
	
	for (i = 0; i < len; i++) {
		set_pixel(x++, y, colour);
	}
}

void vert_line(int x, int y, int colour, int len) {
	int i;
	
	for (i = 0; i < len; i++) {
		set_pixel(x, y++, colour);
	}
}

int main(void) {
	FILE * fout;
	int i = 0, j;
	char * p;
	char lines[MAX_LINES][MAX_CHARS]; // you gotta luv "big" OS's where this works ;-)
	int sizes[MAX_LINES];
	
	do {
		fgets(lines[i], MAX_CHARS-1, stdin);
		sizes[i] = atoi(lines[i]);
		if (sizes[i] > largest_size) {
			largest_size = sizes[i];
		}
		for (j = 0; j < strlen(lines[i]); j++) {
			if (lines[i][j] <= ' ') {
				lines[i][j] = ' ';
			}
		}
		i++;
	} while(!feof(stdin) && i

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way I had intended to follow the MikroE model and have sizes ascending rather than descending but that's yet another artefact of Microsoft's "upside down" Y axis.

If anyone is mad enough to trust un-verified .exe's ver 0.0.0.0.1 (which actually has even started to be version numbered) is attached.

I've just got to move the source over to Linux and build it there to make sure that I haven't relied on anything MS/Windows but when you only include stdio.h I'd hope you can be pretty certain!

Cliff

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well it builds in GCC (12K!) but while it creates a .bmp file it doesn't seem to be valid - I think this is a structure packing issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

YES! :happy:

I guess I should use shorter function names... ;-) (didn't care to sort)

JW

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd recommend PNG rather than JPEG for images with text.
PNG is also better for images with a small number of colors.

I suspect that JVMs, but possibly not java compilers
can be relied on for both Windows and Linux.
I'm not sure what image-related classes can be relied on.
Presumably anyone using avr-gcc is running a developer
system or one with developer packages added.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michael,

Well it's your choice - I'm not planning to produce anything but straight RGB .BMP (as I said, the easeist graphics format in the world (apart from the fact that it's upside down and rasters need to pad to 32 bit boundaries)). In Linux I imagine one could use convert from ImageMagick to make PNG or TIF or whatever you choose. But me, I'm sticking with BMP.

JW,

Wow, that was quite a test. I fixed the image width at 768 pixels (to keep files smallish and to fit in most folks screens at 1:1). Initially I made a "guesstimate" and set 'LABEL_WIDTH' to 100 thinking "that's bound to be enough isn't it?" but it was very soon evident that wasn't enough so this version has it set to 250.

One of the things I plan is to truncate the label strings so there won't be any over-write and if the font has some ellipsis I'll replace the last visible character with that (if it doesn't I'll add one anyway)

Cliff

(the font I'm using is pulled straight out of the Linux kernel tree)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Well it's your choice - I'm not planning to produce anything but straight RGB .BMP (as I said, the easeist graphics format in the world (apart from the fact that it's upside down and rasters need to pad to 32 bit boundaries)). In Linux I imagine one could use convert from ImageMagick to make PNG or TIF or whatever you choose. But me, I'm sticking with BMP.
BMP is only the second easiest,
but the pnm formats don't seem to be as popular.

I only mentioned PNG because I saw the .jpg suffix on an attachment.

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Michaeal,

I just made the attachments to JPG because Freaks has an attachment size limit.

All,

Attached is 1.1 (I'm pretending the first was 1.0). It now truncates the labels and adds ellipsis. It also supports (not very well yet) -?, -h, --help, -v, -version, --ver, etc. (OK two options then!). This was simply so it could respond to -v to identify the versions.

Code as follows:

/*
** Another Beerware prodction from Cliff Lawson
**
** Feel free to abuse this code in whatever way you see fit
*/
#include 

#define VER_MAJOR	1
#define VER_MINOR	1
#define DEBUG_TEXT

// don't want to rely on windows.h so ...
#define WORD short 
#define SHORT short
#define DWORD int
// following is bmp compression format (none)
#define BI_RGB	0

#define BLACK	0x000000
#define RED 	0xFF0000
#define GREEN 	0x00FF00
#define BLUE	0x0000FF
#define WHITE	0xFFFFFF

// pixel width of whole image
#define OUT_WIDTH 768
#define OUT_WIDTH_FLOAT 768.0
// pixel width of the text labels
#define LABEL_WIDTH 250
#define LABEL_WIDTH_FLOAT 250.0
// pixel height of one line of output (8 for font + 2)
#define OUT_HEIGHT 10
// max number of input lines we'll consider
#define MAX_LINES 5000
// max characters on an input line
#define MAX_CHARS 32

extern unsigned char fontdata_8x8[];

typedef struct
{
	WORD   FileType;     /* File type, always 4D42h ("BM") */
	DWORD  FileSize;     /* Size of the file in bytes */
	WORD   Reserved1;    /* Always 0 */
	WORD   Reserved2;    /* Always 0 */
	DWORD  BitmapOffset; /* Starting position of image data in bytes */
} WINBMPFILEHEADER;

typedef struct 
{
	DWORD Size;            /* Size of this header in bytes */
	DWORD Width;           /* Image width in pixels */
	DWORD Height;          /* Image height in pixels */
	WORD  Planes;          /* Number of color planes */
	WORD  BitsPerPixel;    /* Number of bits per pixel */
	DWORD Compression;
	DWORD ImageSize;
	DWORD Hres;
	DWORD VRes;
	DWORD PalColors;
	DWORD ImportantColors;
} BITMAPINFOHEADER;

WINBMPFILEHEADER fileheader;
BITMAPINFOHEADER bitmapheader  = {
	40, 				// This Windows V3 header is always 40 bytes
	OUT_WIDTH, 			// fixed (768)
	0, 					// height will be calculated
	1, 					// RGB24 has just 1 plane
	24, 				//RGB24 (surprise, surprise) use 24 bits per pixel
	BI_RGB, 			// compression is "none"
	0, 					// ImageSize will be calculated
	0xB12,				// a sample file I created used this for "res" - so...
	0xB12,
	0,					// no palette so no colors
	0					// and none "important"
};

int lines_input;
int largest_size;
float xscale;
unsigned char * bitmap;
int bitmap_size;

void render_char(int x, int y, unsigned char c) {
	unsigned char * p, rgb_val;
	int line, mask;
	int raster;
	
	p = (unsigned char *)((y * OUT_WIDTH * 3) + (x * 3) + bitmap);
	for (line = 0; line < 8; line++) {
		raster = fontdata_8x8[(c * 8) + (7-line)];
		for(mask=0x80; mask!=0; mask>>=1) {
			rgb_val = (raster & mask) ? 0x00 : 0xFF; // set black (0x00) if bit set
			*p++ = rgb_val; // B
			*p++ = rgb_val; // G
			*p++ = rgb_val; // R
		}
		p += ((OUT_WIDTH * 3) - (3 * 8)); // 3*8=24 bytes just set/reset
	}
}

void render_string(int x, int y, char * str) {
	while(*str) {
		render_char(x, y, *str++);
		x += 8;
	}
}

void set_pixel(int x, int y, int colour) {
	unsigned char * p, rgb_val;
	int r,g,b;
	
	r = (colour & 0xFF0000) >> 16;
	g = (colour & 0x00FF00) >> 8;
	b = (colour & 0x0000FF);
	p = (unsigned char *)((y * OUT_WIDTH * 3) + (x * 3) + bitmap);
	*p++ = b;
	*p++ = g;
	*p++ = r;
}

void horiz_line(int x, int y, int colour, int len) {
	int i;
	
	for (i = 0; i < len; i++) {
		set_pixel(x++, y, colour);
	}
}

void vert_line(int x, int y, int colour, int len) {
	int i;
	
	for (i = 0; i < len; i++) {
		set_pixel(x, y++, colour);
	}
}

int main(int argc, char * argv[]) {
	FILE * fout;
	int i = 0, j, exit_now;
	char * p;
	char inline[256];
	char lines[MAX_LINES][MAX_CHARS]; // you gotta luv "big" OS's where this works ;-)
	int sizes[MAX_LINES];

	printf("argc=#d\n", argc);
	if (argc>1) {
		exit_now = 0;
		for (i = 1; i largest_size) {
			largest_size = sizes[i];
		}
		for (j = 0; j < strlen(lines[i]); j++) {
			if (lines[i][j] <= ' ') {
				lines[i][j] = ' ';
			}
		}
		// truncate string so it doesn't impinge on graphics
		lines[i][30] = 0;
		if (strlen(lines[i]) > 28) {
			lines[i][29] = 255; // last char is ellipsis
		}
		i++;
	} while(!feof(stdin) && i

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now, if you add a PNG renderer so the result will become a little
less inflated, you're essentially at the level of my Perl script. >:.)

(As Winusers aren't blessed with things like netpbm tools, the tool
itself has to perform the PNG creation I'm afraid...)

Jörg Wunsch

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
Now, if you add a PNG renderer so the result will become a little
less inflated, you're essentially at the level of my Perl script. >:.)

(As Winusers aren't blessed with things like netpbm tools, the tool
itself has to perform the PNG creation I'm afraid...)

Maybe not.
How big is pnmtopng + pngtopnm + pnmtobmp + bmptopnm?

Of course, attachments could just be zipped.
Hmmm. Do zip and PNG use the same compression method?

Iluvatar is the better part of Valar.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
(As Winusers aren't blessed with things like netpbm tools, the tool
itself has to perform the PNG creation I'm afraid...)
Winusers are blessed with usable tools, rather than half-dumb, half-numb command-line-only gizmo. Check out IrfanView, for example.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

Thanks for your work.

Today, I was looking at the SVG format. It appears, that it would be a similar effort to yours to produce pie-charts in that format. It is displayed natively by newer versions of FireFox and Opera, and there appears to be a plugin to M$IE enabling displaying it too.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Check out IrfanView, for example.

I can't. It's not available for my operating system(s).

The *nix equivalent is perhaps xv, but that's a completely
different piece of cake: it requires interaction, so it
cannot be integrated into a build process

Jörg Wunsch

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will put in a plug for Rebol-
www.rebol.com
(grab rebol/view for gui - small download)

simple example for taking an nm output and creating a graph-
http://www.mtcnet.net/~henryvm/t...
http://www.mtcnet.net/~henryvm/t...

here's a nice intro tutorial-
http://musiclessonz.com/rebol_tu...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Curt,

That's impressive - but which Rebol package would need to be included in WinAVR to support this? How big is it and under what licence is it provided?

(meanwhile does anyone know of some open source PNG encoder code?)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All the info is on Rebol.com

http://www.rebol.com/license.html
http://www.rebol.com/view-platfo...

Only a ~1/2 meg download (unlike almost every other programming language out there). No install required (can skip the 'install' if wanted).

It is very cool.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Curt but it's still not clear to me which of /View, /Core, /SDK or /Command would be required.

I have to say, this does look like the best solution proposed so far though, meanwhile, I've been improving my one (see attached) but while I've downloaded libpng, working out which subset of it I should use and how is another story!

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

View would be required, as gui stuff is involved (view includes core). SDK is only needed if you want to produce a single exe (which is basically view.exe combined with script, compressed and encrypted into a single exe), otherwise you simply have view.exe with a script as an argument.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Curt,

Yup I think you sold me on that solution. I downloaded the rebview in both Vista and Ubuntu and then output some "nm" output into a test.txt and ran the script "./rebview -w test.r". On the Windows machine it worked like a dream. On the Linux system I got a .png with green bars created but sadly there was no text - so that would need a bit of work I guess - as you don't actually name a font in the script I don't know why it would have failed but maybe THAT is the problem?

The fact you've got the PNG encoding and everything in the 0.5MB seems like a smallish cost to pay and the great thing would be that everyone who used WinAVR would have the ability to get interested in Rebol if they liked (though maybe the Tcl used by Mfile suggests that people don't use the supplied utilities for much more than the task they are delivered to provide?)

Cliff

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have never tried the linux versions (gui anyway). I think it would probably work ok had I used a normal 'text' field instead of pushing the text down to a 'draw' effect (the draw effect produces nicer looking text, as its anti-aliasing looks better). My simple example has lots of room for improvement.

I'm not sure but I think you could try this for linux-
bold16: make face/font [name: "/path/to/fonts/some.ttf" style: 'bold size: 16]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup that works. In my case I used:
name: "/usr/share/fonts/truetype/msttcorefonts/Arial.ttf"

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phew! - talk about complicated - I finally managed to get the sources of Zlib and libpng to build in VC 9 and I found some useful looking source at:

http://cetus.sakura.ne.jp/softla...

so I "borrowed" bits of that and grafted into my own program to finally create a "makepng.exe" that works just like makebmp (in fact the core is the same so I'm just calling this V1.2 of the same thing).

This 200K .exe is the "debug" build because, for reasons that yet allude me, when I try to build "release" MASM barfs on some of the .asm files in Zlib.

I statically linked everything so this is completely stand-alone. I'm hoping it'll be an easier build in Linux!

Enjoy.

Cliff

EDIT: I found the build options to use C rather than Asm so the .exe including the PNG encoding is 88K

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

your tool seems to like only the first column as size. My version of avr-nm (as of WinAVR20071221) insists on outputting the address into the first column, even with -S.

Do you post-process your symbol files, or is this somehting the newer versions of -nm provide automatically? My point is, if it is a feature of newer -nm-s, can we rely on it to the future?

JW

PS GREAT work with the PNG. Going to test right now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JW,

I'v just been working on the principle that the output of avr-nm is going to be:

D:\c\makepng\Debug>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

D:\c\makepng\Debug>avr-nm --version
GNU nm (WinAVR 20090313) 2.19
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

In the version I just posted there's a new command line paramter "-T " which will filter the nm output on the column after the size for the given character so normally you'd use:

D:\c\makepng\Release>avr-nm --size-sort -t decimal \sounds\avrapp\sounds.elf | makepng -T T

which also strips that middle column out to give a display such as...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh, the --size-sort WITHOUT -S does the trick, not the particular version of avr-nm...

But thanks for the extra parameter (although I can't see how did you use it in your example above, and how do you mean "size of given character" - I am particularly stupid today). It might be useful if one does NOT want to sort by size.

Jan

[edit] now I se you've fixed the example and undertand how it is intended to work, it's great, thanks again

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to say that I just moved the four source files into Ubuntu and with a couple of tweaks (what kind of idiot uses a variable called 'inline' anyway? :lol: - GCC is more picky than MS cl.exe) it builds and works just fine. The executable in Linux is just 21,925 bytes

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.mtcnet.net/~henryvm/t...
http://www.mtcnet.net/~henryvm/t...

I updated my code a little to make it look a little nicer :) One could tweak for days until something 'really nice' comes out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, this is my first post here, so welcome me :)

Why not simply generate an html page with std::fstream or similar? If you put the data into a javascript array, you could add support for ascending/descending sorting and other interactive features.

I might give it a shot myself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Works on my Vista machine, however the bar-graphs don't seem to represent the size. Since I'm an idiot, what exactly are the bars telling me?

Also, I think it would be useful to have the output group according to the data type -- one section for SRAM, another for EEPROM and a final one for FLASH (static, weak, strong and normal data).

- Dean :twisted:

Attachment(s): 

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought this had died but here's the latest one (V1.3) which now draws "pretty bars". It's important that the avr-nm output shows (decimal!!) sizes and only sizes, not addresses. So use --size-sort and '-t decimal' on the avr-nm invocation. To filter a particular output type (T, B, D) use the -T (Type) option to makepng.

So a typical invocation is:

avr-nm --size-sort -t decimal file.elf | makepng -T T

Here's some pretty bars...

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Much better! I found the following to be useful:

avr-nm --size-sort -t decimal BootloaderDFU.elf | egrep " (T|t|W|w) " | makepng

That will only show global, static and weak functions in the output, and exclude all else. Great for my bootloader (see attached).

I'd like to see something like this (or, as mentioned, a HTML generating equivalent) into the next WinAVR package, as it's useful for a visual size comparison.

- Dean :twisted:

Attachment(s): 

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guess who forgot to attach V1.3 :oops:

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh and if anyone has a copy of MS VC++ 8 Express then all the project files to build the Windows .exe are in:

http://www.wrightflyer.co.uk/mak...

It's a 2.3MB download but that's mainly because contains copies of both the libpng and zlib source. I have this in d:\c\makepng, d:\c\libpng-1.2.37 and d:\c\zlib - as there may be absolute paths embedded it probably needs to be in the same place to build (which is where subst comes in handy ;-)).

The "solution" file that pulls everything together is the makepng\makepng.sln file, so just load that into Vis Studio

Rather amusingly in Ubuntu (where zlib and linpng(12) are probably already installed or can easily be got with apt-get) you only actually need:

makepng.c, font.c, writepng.c and makepng.h

and build with:

gcc makepng.c writepng.c font.c -o makepng -lz -lpng12

There's no more to it than that - I didn't even bother with a Makefile (one of the MANY reasons why software development is so much easier in Linux)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

the new graph is very pretty... ;-)

Here is the new version of the map checking utility I have thrown together, with some readme, a .bat file generating a few pictures (the masochist types can just use make for that :-P - note that I am using the "sort" program (what a @#$%^ idea to call programs to be confused with ordinary words), which is distributed together with WinAVR), and a rudimentary html file, just as a very rough example what would I expect to have.

Some pictures attached here.

Jan

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah, I thought it was an abberration but I notice that your pictures have a coloured line down the right edge as I've been seeing. Not sure if this is in my memory DC that I'm painting too or some error I'm making in invoking the PNG encoder (maybe I'm getting the width 1 pixel wrong or something?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What values would you suggest in the config for an ATMEGA2560?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dbvanhorn wrote:
What values would you suggest in the config for an ATMEGA2560?
Well, I'm not sure if you meant my checkmap utility, but if yes - the idea is that a config will be written for the internal resources of each avr and then some magic in make would check the appropriate model. I intended this as one of the small enhancements of progmem/far management.

However, I am now too busy with the work which pays the bills to sit down and create all the zillion config files needed. If I get to it, I'll start with the ATMega256x, I promise (anyway, that's one of the targets what I am working at now, and that's for which I needed all the progmem-far stuff I plan to share).

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Resurrecting one more zombie... I updated the crude checkmap utility I concocted some time ago.

The main change is, that it now goes through the list files too, collecting primarily stack usage information. Problem is, that that information changes from issue to issue of avr-gcc, so there's some "black magic" involved, and its usage is limited. It may be fun nevertheless.

Enjoy - strictly at your own risk... :-)

JW