Files sizes problem!!

33 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

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.

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

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

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

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/Intel_HEX[/url]

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

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.

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

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

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

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

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

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.

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

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.

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

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.

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

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

Pages