Hi guys,
I am currently using the evaluation software C51 tool kit to compile my c code into machine code. Apparently, this version of software has a limitation of 2k of object code. At first I thought that will be a .hex file, but then after I manage to squeeze my code size to a size that the version is able to compile (before that it always comes out with a message saying I exceed the 2k limit), I realise that my .hex file is around 8kB, so it is clear that that is not the one. I would like to ask what does it mean by object code? Which will be the file that cannot exceed 2k of size? Shouldn't be the one with .obj as well I think, as those exceed 2k as well.
Thanks guys.
Regards, Siang
An object file constains a lot of data besides the "machine code" you talk about. The size of the object files will also be affected by debug information. Obviously it wouldn't be good if max size would be affected by the length of your variable names or function names.
A hex file is just a more verbose representation of a program, where each byte in the processor is represented by two bytes in the hex file. The hex file also contains checksum information, address information etc. Oviously it isn't meaningful to use the size of the hex file.
The only meaningful way is to count number of bytes inside the processor after a program is loaded.
Actually, the compiler does this for you and gives you the numbers at the end of the compilation.
Or you check the list files.
what is my program size then?
Program Size: Code=27636 RO-data=676 RW-data=496 ZI-data=27516
the binary on the hard disk without debug information is 34,164 bytes long.
So do you mean that the file size of the .hex file is not the size of information that is going to occupy the memory in the processor? Lets say I am downloading the 8k of .hex file into a flash memory on a microcontroller to run it later on, how much memory will be occupied? Is it the whole 8k or it will be less than that 2k (the limit of object code) because it doesn't include those checksum information etc.?
The microcontroller that I am using only has 8k of flash memory, thats why I need to know this so that I would know whether I need to get external memory for this or not. Thanks.
There are no easy rule to deduce code size from a hex file. It is less than half the hex-file size. Probably about 40%.
But when thinking about limited compilers: Some compilers just count amount of code space. Some includes amount variable space used too, when figuring the limit for the evaluation version.
That is why it isn't good to look at the download files. The documentation for the compiler should say what blocks that are included, and then you normally look at the map file or explicit size information being emitted in the build log.
Note that a binary file does not contain any address information. If the code has holes, then the binary file must fill these holes with 0x00 or 0xff, which means that a binary file may be bigger than what is expected from the build log output.
Does your code contain both a boot loader and an application? It seems like the binary file has filled a gap between two code blocks to become as large as it is.
As Per pointed out, the hex file size does not directly reflect the code/data size of your program. With the evaluation tools, you can compile code that exceeds the 2K limit but the linker restricts object code to the 2K limit. The Keil object file is found in your project files with the same name as your project but with NO file extension. Object files can contain symbol linkage for source level debugging but the object to hex converter will strip these symbol links. I agree with Per that a fair rule of thumb is the actual binary code size will be about 40% of the hex file size. Bradford
Program Size: Code=27636 RO-data=676 RW-data=496 ZI-data=27516<p>
That doesn't look like the output from C51, but rather like that of the ARM compiler.