Map file analysis tool

Go To Last Post
102 posts / 0 new

Pages

  • 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

Pages