AVR Freaks

AVR Microcontrollers, megaAVR and tinyAVR

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

Posted by ia17348: Sat. Apr 12, 2008 - 01:38 PM

Hello...

I did debugging for my code on code vision 1.25.6 with AVR studio debugger and I noticed a thing, the size of hex file of code vision is much larger than the hex file of avr studio 4 .

Would you please tell me about :
1) The reason of difference in the size of hex files between the two programs.
2) Is it possible to use the the hex file of avr studio to download the program on a uC using kanada200/300 programmer with code vision..
3)When we speak about high code density of AVR uCs and flash memory size ,which size do we mean (which file do we intend ?)?

:?: :!: :idea:
thanks in advance...

Tags:

Level: Resident

Joined: Wed. Mar 19, 2003

Posts: 738 View posts

Posted by gahelton: Sat. Apr 12, 2008 - 03:05 PM

1. Isn't Codevision a C complier ?

Of course the code written with a C compiler and "compliled" will almost certainly generate a larger hex file than an assembly file (written and "assembled" with AVR Studio).

2. Your programmer should not care how your hex file was generated. As long as it's a vaild hex file format and will fit into the controller, it should work.

3. A hex file can be generated from lots of different assemblers, compilers, etc. It is a file which defines the what the binary information is, and where it goes - its that simple. A larger hex file means that it will use more of your uCs memory. If you want smaller hex files, then you will need to optimize your code. Of course, if the hex file which defines your flash memory won't fit into your particular uC, and you can't optimize any further, then you will have to upgrade to a uC with more memory.

CountZero

Level: Resident

Joined: Thu. May 27, 2004

Posts: 678 View posts

Location: Sweden

Posted by CountZero: Sat. Apr 12, 2008 - 08:01 PM

The size of the hex file does not necessarily reflect the binary size.

Level: Resident

Joined: Wed. Mar 19, 2003

Posts: 738 View posts

Posted by gahelton: Sat. Apr 12, 2008 - 09:17 PM

The size of the hex file is representative of the binary file size. Below is an example of line from a hex file and a breakdown of the sections.

DS AAAA RT DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDCS
: 14 0050 00 0C948B0E0C948B0E0C948B0E0C948B0E0C948B0E7F

where
DS is the number of data bytes for this line
AAAA is the starting address for data on this line
RT is record type (00 = data record, 01 = end)
DDDD... is data
CS is checksum

All of these values are in hex.

To get a good estimate of the size of your binary image, take the data size(DS) times the number of lines in your hex file - 1 (don't forget this is hex).

The last line normally looks like this

DS AAAA RT CS
: 00 0000 01 FF

There is no data on this line (LL = 0), address is irrelevant, Record Type is 01 (end of record).

The binary file size estimate is most accurate when there aren't a lot of different segments within the program space. At the end of each segment, lines that are different lengths may be created. But for most users, this isn't the case and the estimate works well.

If you are interested, here is a link with more details on the hex file format.

[url]
http://en.wikipedia.org/wiki/Int...

theusch

Level: 10k+ Postman

Joined: Mon. Feb 19, 2001

Posts: 40127 View posts

Location: Wisconsin USA

Posted by theusch: Sun. Apr 13, 2008 - 12:25 AM

Quote:

The size of the hex file does not necessarily reflect the binary size.

Quote:

The size of the hex file is representative of the binary file size.

Make up your mind, people. You are going to get OP all confused.

Certainly, a larger output file from the same tool is also probably indicative of a larger binary.

But a larger .HEX from different tools is not necessarily indicative of a larger binary. gahelton did some of the analysis--see his "DS". One tool may use a different DS than another and have vastly different .HEX file size.

This is all somewhat of a tempest in a teapot anyway. Yes, we have seen posts like this one from OP: "That darned GCC compiler is a piece of crap 'cause for my blinky '2313 test program the .HEX file is 2345 bytes and won't even fit." Yes, we know that it could still be a quite modest program that fits nicely into the flash space.

Note also that a tiny .HEX file size may stil have a program that does not "fit", if .ORGed or linked to nonexistent address space.

And certain tools may use the .HEX file for other than flash purposes.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

Posted by ia17348: Sun. Apr 13, 2008 - 06:03 PM

Quote:

Of course, if the hex file which defines your flash memory won't fit into your particular uC, and you can't optimize any further, then you will have to upgrade to a uC with more memory.

Hello again..

Now I can understand that the size of the flash memory of the uC is related to .HEX file , so what's the purpose of the "Atmel flash contents file" .
And about the upgrading , if I'm using an ATmega8535 (8KB flash memory) for example ,and I needed a (16KB) or (32KB) flash memory, can I use ATmega16 or ATmega32 without changing the program????

danni

Level: Raving Lunatic

Joined: Wed. Sep 5, 2001

Posts: 2960 View posts

Posted by danni: Sun. Apr 13, 2008 - 06:21 PM

gahelton wrote:

The size of the hex file is representative of the binary file size.

Thats rubbish.

E.g. the hex file of my ATmega2561 Bootloader has a size of 1520 bytes.
But it dosnt fit on an ATtiny2313 nor any other AVR below 256kB (0x40000).

If you use WINAVR or Atmel Assembler you can get an output of the real last used address.
E.g.:

ATmega2561 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x03fc00 0x040000    504     20    524  262144   0.2%

End = 0x040000 means, that only a device of at least 0x40000 bytes of Flash was able to be programmed with this code.

The naming "End" was not true, because it point after the last byte.

But you can see, that the hex file (1520 byte) of the Atmel assembler was about three times of the used space (524 byte), without gaps.
It may differ on other assemblers depending from the record length.

Peter

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

Posted by david.prentice: Sun. Apr 13, 2008 - 06:46 PM

ia17348 wrote:

Hello again..

Now I can understand that the size of the flash memory of the uC is related to .HEX file , so what's the purpose of the "Atmel flash contents file" .
And about the upgrading , if I'm using an ATmega8535 (8KB flash memory) for example ,and I needed a (16KB) or (32KB) flash memory, can I use ATmega16 or ATmega32 without changing the program????

If you are using the Atmel Assembler then you need to .include the device-specific header file. And ensure the correct size of interrupt vector table.

If you are using C, you will need to either #include a device-specific header file or just alter the project configuration to set the new processor. The C compiler will look after your vector table.

So you have to do something. ... but not a lot.

David.

Level: Resident

Joined: Wed. Mar 19, 2003

Posts: 738 View posts

Posted by gahelton: Sun. Apr 13, 2008 - 08:20 PM

Peter,

Please read the entire contents of the post get a better understanding of the hex file format. My comment that the size of the hex file was "representative" of the binary file size does not mean that the size of a hex file vs the size of the binary image is a one for one match - far from it.

The hex file format is an ASCII format with an 11 byte (ASCII) overhead per hex file line. Typical data bytes per line are 16 and 20 (32 and 40 actual hex file bytes because of the ASCII format). The only real varaible in the format is the number of data bytes per line. For a given tool, a larger hex file size will almost certainly yield a large binary image. If anyone can find an example of where that isn't true, I would love to see it. However, you can easily see that it would possible to create such file. For example, if you data size per line (DS) were 01, then the hex file format overhead would overwhelm the actual data in the file. But, tool vendors don't do this for obvious reasons.

The technique described in my previous post works for binary image estimates. Your comments that the tools give you the binary size (either directly or indirectly) is spot on. Most tools create a .map file, or something similar, where you can get memory usage information. This is actually the first place anyone should go if there is a question about memory usage.

Koshchi

Level: 10k+ Postman

Joined: Wed. Nov 17, 2004

Posts: 15658 View posts

Location: Vancouver, BC

#10

Posted by Koshchi: Sun. Apr 13, 2008 - 08:22 PM

Quote:

So you have to do something. ... but not a lot.

This really depends on which AVR you are coming from and going to. The main difference between a mega8535 and a mega16/32 (aside from memory size) is that the latter has a JTAG interface, the former does not. So in this case, it should be pretty trivial to port.

Regards,
Steve A.

The Board helps those that help themselves.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#11

Posted by ia17348: Tue. Apr 15, 2008 - 03:16 PM

Quote:
So you have to do something. ... but not a lot.

As for me , I'm using code vision , and the only thing I did to substitute ATmega8535 with ATmega16 or ATmega32 is just changing the header file .

As for sizes problem , I could download a 12Kbyte .hex file on an ATmega8535(8KB flash) "about 26KB flash contents files" , is there any relation between this possibility and AVR code density techniques ?????

Level: Resident

Joined: Wed. Mar 19, 2003

Posts: 738 View posts

#12

Posted by gahelton: Wed. Apr 16, 2008 - 01:50 AM

ia17348,

The "BEST" way of determining your total code usage is to look at your .map file. This file should be in your project directory. The .map contains all sorts of useful information about memory usage, variable storage locations, etc. This should be the first place to look for memory questions. The binary file size estimation techniques should only be used as a last resort if no other method is available.

I am not a CV user, so I don't know if there are any compiler switches that need to be set to generate a .map file; although, I would suspect that that a .map would be generated by default. Look in your project directory for the .map file and open it with a text editor. If you can't find it, read your CV documentation for a way to generate it.

theusch

Level: 10k+ Postman

Joined: Mon. Feb 19, 2001

Posts: 40127 View posts

Location: Wisconsin USA

#13

Posted by theusch: Wed. Apr 16, 2008 - 03:13 AM

Well, actually, since CV only compiles (with current version) from within the IDE, it is right there in front of you after each build:

Chip: ATmega169
Program type: Application
Memory model: Small
Optimize for: Speed
(s)printf features: int, width
(s)scanf features: int, width
Promote char to int: No
char is unsigned: No
8 bit enums: Yes
Enhanced core instructions: On
Automatic register allocation: Off

16039 line(s) compiled
No errors
28 warning(s)

Bit variables area: 2h to 3h
Bit variables size: 2 byte(s)

Data Stack area: 100h to 17Fh
Data Stack size: 128 byte(s)
Estimated Data Stack usage: 50 byte(s)

Global variables area: 180h to 49Ch
Global variables size: 797 byte(s)

Hardware Stack area: 49Dh to 4FFh
Hardware Stack size: 99 byte(s)

Heap size: 0 byte(s)

EEPROM usage: 491 byte(s) (95.9% of EEPROM)
Program size: 7739 words (94.5% of FLASH)

("Assembler" pane)
AVRASM: AVR macro assembler 2.1.9 (build 90 Jul  5 2006 11:06:16)
Copyright (C) 1995-2006 ATMEL Corporation

ATmega169 memory use summary [bytes]:
Segment   Begin    End      Code   Data   Used    Size   Use%
---------------------------------------------------------------
[.cseg] 0x000000 0x003c76  15248    230  15478   16384  94.5%
[.dseg] 0x000100 0x00049d      0    797    797    1024  77.8%
[.eseg] 0x000000 0x0001eb      0    491    491     512  95.9%

Assembly complete, 0 errors.

The .HEX file for the above is reported as 43KB, and the .ROM (another output representation) is 99KB.

Quote:

I'm using code vision , ...

As for sizes problem , I could download a 12Kbyte .hex file on an ATmega8535(8KB flash) "about 26KB flash contents files" , is there any relation between this possibility and AVR code density techniques ?????

I don't entirely get the point, or the question. First 12kbyte; then 26KB. Are these different .HEX files, and the size on disk of each? As roundly discussed above, in general from the same tool (CV in this case) the larger the program the larger the file on disk. And yes, you could create an app with pieces located all over flash.

What does the build summary tell you?

What are "AVR code density techniques"? CV, as with other compilers, will have different options. In short, you build for "Size" or Speed". The savings in space with "Size" will depend almost entirely on the app and how you write >>your<< code.

The same thing really applies in general: >>You<< need to become familiar with the AVR, and the code generation model of your compiler brand, and write the C code so that the compiler can generate efficient sequences. I can write a 10-line program doing a few float computations and output the results using the biggest printf() and virtually fill up a Mega88. Or I can write a quite detailed app and have it fit quite nicely, thank you.

What I do with CV is to scan the composite .LST file during development and look for obviously bloated sequences--many, many machine language instructions for a single C line. Often you can help the compiler with a well-placed cast, or re-do the sequence so that you do not force the compiler to go through all the shenanigans.

Have you looked at the results panes, and the .LST file?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#14

Posted by ia17348: Fri. Apr 18, 2008 - 10:39 AM

gahelton said

Quote:

The "BEST" way of determining your total code usage is to look at your .map file.

Here's the .map file for the project I'm talking about:

Quote:

CodeVisionAVR C Compiler V1.25.6 Professional
(C) Copyright 1998-2007 Pavel Haiduc, HP InfoTech s.r.l.
http://www.hpinfotech.com

File: F:\AT90S8535\PWM+Keyboard.c
Global variables memory map:

Variable Address Size
i R4,R5 2
temperature E0h 2
Decimal_value R7 1
T R8,R9 2
number E2h 16
x100 R6 1
x10 R11 1
x1 R10 1
mode F2h 1
temp R12,R13 2
_base_y_G2 F3h 4
_lcd_x F7h 1
_lcd_y F8h 1
_lcd_maxx F9h 1

this file shows that just little size was taken by variables , I couldn't understand how to determine the size of code using this file....

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#15

Posted by clawson: Fri. Apr 18, 2008 - 11:01 AM

In the case of CV clearly the .map file is not of much use in determining this (Lee already told you that the report at the end of the build in the IDE is where you'll actually find all you are looking for). In other compilers that are linking compilers the .map file is a more powerful tool as each .c file is compiled in complete isolation and then another tool (the linker) "glues" all the bits together and one of it's outputs is a .map file that tells you what went where and how big it was. But CV doesn't work like this and its .map file is for a different purpose.

Bottom line: ignore then .map file comment

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

#16

Posted by david.prentice: Fri. Apr 18, 2008 - 11:05 AM

Lee showed you what report you get for every CV compilation. You can always see the last report by clicking the little blue "information" icon.

I should not worry about hex files or formats.

You just keep an eye on the data , stack and flash usage. If you have completed your project and it seems to have lots of spare space:

Change the mcu type to a smaller AVR and re-compile. If this has enough space then you know you could use this smaller AVR in a production board.

It is easier to develop with a large AVR, and check later. So you design your board for a certain number of pins. Develop the code. Populate the board with the smaller and cheaper AVR.

There are several tips for saving space in an application. But there is seldom any point unless you can derive a cost saving by using a smaller AVR.

David.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#17

Posted by ia17348: Fri. Apr 18, 2008 - 11:43 AM

Quote:

EEPROM usage: 491 byte(s) (95.9% of EEPROM)
Program size: 7739 words (94.5% of FLASH)

Do you mean that the real and accurate size is determined by this two lines???

Quote:

First 12kbyte; then 26KB. Are these different .HEX files, and the size on disk of each?

No they aren't, the first one is .hex file wich has the size 12KB(16KB size on disk) , and the file flash contents is just another file generated by AVR studio (Debugger of CV) after building (I don't know what's the purpose of it).

The build summary tells me...

Quote:

Chip: AT90S8535

Memory model: Small
Optimize for: Size
(s)printf features: int, width
(s)scanf features: int, width
Promote char to int: No
char is unsigned: Yes
8 bit enums: No
Automatic register allocation: On

4576 line(s) compiled
No errors
No warnings

Bit variables
size: 0 byte(s)

Data Stack area: 60h to DFh
Data Stack size: 128 byte(s)
Estimated Data Stack usage: 66 byte(s)
Global variables area: E0h to 14Ah
Global variables size: 107 byte(s)
Hardware Stack area: 14Bh to 25Fh

Hardware Stack size: 277 byte(s)

Heap size: 0 byte(s)

EEPROM usage: 0 byte(s) (0.0% of EEPROM)
Program size: 2516 words (61.4% of FLASH)

A small question here , your file has a part on the EEPROM ,I don't know how to make the EEPROM in use so all the projects I did didn't use the EEPROM???

Quote:

What are "AVR code density techniques"?

I don't a lot about it but I can give you an image taken from a file (by Mr. John Carey The Technical Marketing Manager of ATMEL).

Quote:

Have you looked at the results panes, and the .LST file?

I didn't understand what do you mean by results panes, and about .LST file , I saw it- its size is 160KB in my project - do you mean that you use this file to know what is the code you can reduce from your program ,by sequencing the steps your self not depending on the compiler ???

Thanks for giving attention..
Isam

Attachment(s):

code density.JPG

Last Edited: Fri. Apr 18, 2008 - 12:15 PM

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#18

Posted by clawson: Fri. Apr 18, 2008 - 12:08 PM

Quote:

Program size: 2516 words (61.4% of FLASH)

In that case I'd expect the .hex file on disk to be about 6K (times by 2.5 or 3 usually works for comparing ASCII and binary sizes). If the generated .hex is much larger than this then it may be "sparse" and padded. It'd be interesting to see you post the built .hex file as an attachment.

Cliff

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

#19

Posted by david.prentice: Fri. Apr 18, 2008 - 12:13 PM

ia17348 wrote:

Quote:
EEPROM usage: 491 byte(s) (95.9% of EEPROM)
Program size: 7739 words (94.5% of FLASH)

Do you mean that the real and accurate size is determined by this two lines???

Hello ia. My name is David.

Yes. This is all you need to know.
And in your case you have 0% and 61.4% so you can NOT use a smaller AVR (which would be 50% of your 8535)

You have plenty of space for your code to grow, and you will still fit in your 8535. You also have plenty of hardware stack, far more than you ever need. So you can use more RAM if needed.

Quote:

What are "AVR code density techniques"?

A load of marketing mumbo-jumbo. Basically will your program fit in a 8kb AVR or a 8kb PIC. (Yes I know they both use program words but they advertise as 8kb.) Unless you have to pay more for a larger size chip, it does not really matter.

David.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#20

Posted by ia17348: Fri. Apr 18, 2008 - 12:39 PM

First of all ,I was replieng Mr. theusch before I read your posts Mr.clawson and Mr.David so I'm sorry for asking questions you answered before ...

Mr.clawson

Quote:

In that case I'd expect the .hex file on disk to be about 6K (times by 2.5 or 3 usually works for comparing ASCII and binary sizes). If the generated .hex is much larger than this then it may be "sparse" and padded. It'd be interesting to see you post the built .hex file as an attachment.

1)My .c file has lots of comments , does that has any effect??
2)Would you please tell me what do you mean by "times by 2.5 or 3 usually works for comparing ASCII and binary sizes" ???
As for .hex file , I noticed that its size has increased by almost 6KB after including LCD.h,stdio.h,stdlib.h,and 3KB after using sprintf and ftoa...
and this is my .hex file...
(this file is the same for AT90S8535 and ATmega8535)
thanks for giving time...

Isam

Attachment(s):

PWM+Keyboard.hex

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

#21

Posted by david.prentice: Fri. Apr 18, 2008 - 12:48 PM

Isam,

1. Comments do not go into the hex file at all.
2. Look at the Intel Hex. Most lines are 16 bytes so you have 44 chars for 16 bytes of actual binary. 44/16=2.75
3. You increase nothing with .h files.
4. You do increase size by using expensive functions like printf() and floating point maths like ftoa().
5. If you change the printf() option in your Configure, you will get far larger size. But you may need to use the extra features like %f
6. Your hex file is of no interest to anyone.

David.

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#22

Posted by clawson: Fri. Apr 18, 2008 - 12:51 PM

1) Nope but I was impressed that your report said 4576 lines of code to generate just 2,516 bytes of binary - that's always a good sign that the code is fairly well commented (course you could have just fleshed it out with the text of "War and Peace" I guess! ;) )

2) on the whole printf() (and other derivatives of vs_printf) "cost" about 1.5K..2K in a project (though often several printf support libriaries are provided so you can pick a "smaller one" as your needs vary). Similarly support for float variables generally "costs" 1.5K..2K too which is why a lot of engineers programming small devices prefer to use ints/longs instead.

As for the x2.5 to x3 thing your posted file demonstrates that. For each byte of program (say 0xE5 or 0x37) the file contains TWO characters 'E'+'5' or '3'+'7' so, simplistically you'd have said that a .hex file would just be double the size of the binary that it represents. However there are some other info on each line (such as the destination flash address for each group of 16 bytes) so it's a bit more than just x2

In your case the .hex file is 14,172 bytes and it actually contains the code for flash addresses 0x0000 to 0x13A7 - so that's 0x13A8 bytes or 5,032 bytes of code. In this case the ratio is actually 14172/5032 = x2.8

So, like I said, if you want to know how much code a .hex file contains just consider using an x2.5 to x3.0 factor. (x2.8 fits neatly into that range)

(of course there are things such as "sparse" and "padded" .hex files so using a .hex file size to estimate the binary size is not ALWAYS guaranteed to work in this simplistic way - which is why it's far better to get the C compiler or assembler to actually tell you how many bytes of binary it has output)

Cliff

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#23

Posted by ia17348: Fri. Apr 18, 2008 - 12:52 PM

Hello David my name is Isam ...

I agree with you..
What I know that all programs will be converted to binary form to be downloadable to the uC .
Is there any differences between binary form file of avr and binary form file of PIC !!!!
I think the difference appears just in code...

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#24

Posted by clawson: Fri. Apr 18, 2008 - 12:54 PM

Quote:

Is there any differences between binary form file of avr and binary form file of PIC !!!!

On the whole that's the joy of using C rather than Asm. Under the hood the micros may be speaking French or German but your are writing in Esperanto at a level above all that, then the compiler converts your Esperanto into French or German as appropriate

(what an awful metaphor! ;) )

The Asm opcodes and functionality (even the mnemonics) are quite different comparing between PIC and AVR (and 8051 and 6800 and Z80 and whatever...)

bobgardner

Level: 10k+ Postman

Joined: Wed. Sep 4, 2002

Posts: 26609 View posts

Location: Orlando Florida

#25

Posted by bobgardner: Fri. Apr 18, 2008 - 01:14 PM

The big picture is that the guys that invent these computers also invent the instructions and opcodes... and they are all different... in a few cases, one could burn the program designed and written for an avr mega16 into a mega32 or 128 perhaps, but it still might not run if something very simple was different and not accounted for... location of stack, location of certain registers in the memory map... I met a few computer science guys that grasped the concept of 'hi level language: readable by humans. Compiler converts to machine language: readable by computer' Then he assumed that the output of the 68000 compiler would just run on the VAX. Here's an analogy... computer instructions are to the computer they run on as human languages are to the country in which they are spoken. So Atmel procesors speak 'AVR instructions' and Microchip cpus speak 'PIC instructions' and Intel cpus speak 'Pentium instructions'. That stretching it too much? And as to the 'code density' concept, that has to do with the 'cleverness' and 'elegance' of the instruction set. Certain classic computers have been respected because they were easy to program... had just the right mix of instructions and registers and memory addressing modes.... PDP11, 68000, 6809... other cpus are regarded as hard to program because of no instruction to do certain common operations, not enough registers with certain often used modes. That chart is Atmel bragging that the AVR takes fewer instructions to express some algorithm than all those other cpus.

Imagecraft compiler user

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#26

Posted by ia17348: Fri. Apr 18, 2008 - 01:26 PM

Quote:

2. Look at the Intel Hex. Most lines are 16 bytes so you have 44 chars for 16 bytes of actual binary. 44/16=2.75

Quote:

As for the x2.5 to x3 thing your posted file demonstrates that. For each byte of program (say 0xE5 or 0x37) the file contains TWO characters 'E'+'5' or '3'+'7' so, simplistically you'd have said that a .hex file would just be double the size of the binary that it represents.

Do you mean :
(number of chars per line)/16B=ratio
(number of bytes)/(flash address range)=ratio
the real size for the .hex file = size/ratio

Quote:

3. You increase nothing with .h files.

If not,When I include a header file how does the included file included in the program downloaded to the uC ??

Quote:

If you change the printf() option in your Configure, you will get far larger size. But you may need to use the extra features like %f

I used C++ for some simple projects on computer , sometimes we could use just some functions of the included header file to reduce used area of memory,
is it possible with C for AVRs???

Quote:

6. Your hex file is of no interest to anyone.

Please , Don't forget Cliff :wink:

Isam

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#27

Posted by clawson: Fri. Apr 18, 2008 - 01:33 PM

Quote:

When I include a header file how does the included file included in the program downloaded to the uC ?

In properly written code the .h files will not generate ANY code so there #include'sion will have no effect on the final binary size - they are just a way of an author of some "lib" function providing you with the documentation of how the interface to their function works. It's when you include the lib itself during the linking phase that the code that the .h file refers to gets "pulled in" (if properly written only the used parts of a lib will be pulled in). Some of the code you pull in isn't as the result of an explicit function invocation but is an implicit side effect of using some operator (like +,-,*,/ with float variables)

Of course CV is not a linking compiler in this sense but it does have a clever mechanism whereby it only builds in selected parts of some .c code that effectively constitutes its "run time library" (aka "libc" and "libm")

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#28

Posted by ia17348: Fri. Apr 18, 2008 - 01:36 PM

Quote:

And as to the 'code density' concept, that has to do with the 'cleverness' and 'elegance' of the instruction set.

That chart is Atmel bragging that the AVR takes fewer instructions to express some algorithm than all those other cpus.

You mean this is the reason of the high speed of AVRs (up to 20MIPs).....

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30664 View posts

Location: Wormshill, England

#29

Posted by david.prentice: Fri. Apr 18, 2008 - 01:44 PM

ia17348 wrote:

Quote:

You mean this is the reason of the high speed of AVRs (up to 20MIPs).....

You mean that you believe every washing powder is new and improved. :shock:

David

KKP

Level: Resident

Joined: Tue. Jun 26, 2001

Posts: 842 View posts

Location: Silkeborg, Denmark

#30

Posted by KKP: Fri. Apr 18, 2008 - 01:50 PM

the hex data length effect:

I have a radio with a CAN128 inside. The code is 0x53CA bytes long, 21k.
http://n1.taur.dk/avrfreaks/hexmogrify.zip is a windows app I wrote to test a hex loader; It can transform a hex file with one data length into one with a different data length.

The 21k code, with a data length of 32, is 51k hex. With a datalength of 255 it's a 43k hex, and with datalength set to 1 it is a gigantic 315k hex.

PIC world:
The pic world has two oddball formats I call pichex16 and pichex17. pichex17 is like intellec hex, only there are twice as many bytes in a 00-type line as one would expect, and the addresses are word addresses. pichex16 is the same, only byte swapped. The problem is that they look somewhat like intellec hex, and while they can be distinguished from intellec hex by parsing them, they cannot be distinguished from each other. Microchip's tools used to generate those, I think - that was when the PIC16C84 was hot, and it may have changed since then.

Level: Wannabe

Joined: Sat. Dec 29, 2007

Posts: 95 View posts

#31

Posted by ia17348: Fri. Apr 18, 2008 - 01:52 PM

david.prentice wrote:

Quote:

You mean that you believe every washing powder is new and improved

You tell me not to believe ATMEL :twisted: 8) :mrgreen: :shock: :wink:

Isam

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101861 View posts

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

#32

Posted by clawson: Fri. Apr 18, 2008 - 02:08 PM

Quote:

You tell me not to believe ATMEL

It's more general than that - never believe benchmarks.

In fact it's probably even more general than that - as David implies - never believe ANY marketing BS whatsoever whether it be about the performance of your CPU, your car, your washing powder or whatever.

Remember that there are lies, damned lies and statistics. (and you can probably prove black is white with the latter)