We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
hello, I have made a program in assembly language (using keil) . After creating the hex file for the project in Intel hex format the size is coming around 348 bytes. However when I am loading this file in my programmer for burning the size is coming to be 118 bytes. how do i fix this?? Programmer is mini-usb interface universal programmer( locally made)
hey man. we saw this too. it was a bug in the math of the programmer. you look 384 \ 118 is 3. programmer did not give good answer.
"how do i fix this??"
Why do you assume there is anything to fix?
Why do you feel that the hex file must have identical size to the amount of binary bytes consumed by the program when loaded into your processor?
Any suggestion how to correct it..?? P.S I thought i was the only one..:)
I did not mean that HEX file after being burned in the microcontroller is consuming less space. The problem is that hex file that is being loaded in PROGRAMMER for burning is of smaller size. If this is also normal ,could you please explain thank you
As far as i know it is the hex file that is written as it is in the microcontroller's memory. Now the size of the hex file that is produced by project is given in bytes.So when i burn this file in my microcontroller i expect them to be of the same size .At least the one that is being loaded to be burned should be of the same size. Am i wrong somewhere?
Not sure I (quite) understand what you're saying?
What, exactly, do you mean by, "hex file that is being loaded in PROGRAMMER" as distinct from, "hex file on computer"?
Often (generally?), PROGRAMMERS don't store the hex file - just the binary that it represents.
How do you obtain the sizes of these two "files"?
Have you compared the contents of the two files - maybe one contains some "padding"?
Remember that Windows reports the size occupied by the file on the disk - which may be larger than the content of the file (because disk space is allocated in "chunks")...
The GUI terminal of my programmer has an option load ,where the hex file to be burned is selected .Although I cant see or open the file but the display window of programmer says Load successful 118 bytes
The chunk size for the hex file on system is displayed to be 1 kb,but when check the properties it comes out be 348 bytes.I hav tried deleting all the white spaces.
Pardon? For all versions of Windows I've used, I've not seen that. Not tried Windows 8 because it looks shite. Looking at explorer, the value is simply rounded to KB or MB etc. If you look at properties, you normally get a report of size and size on disk.
Besides, a chunk size of 384 would be a very unlikely value.
That said, I know what you're trying to say. Just had to highlight that questionable statement.
Andrew Neil, Per Westermark Brilliant , thank you.
The value shown in the 'Size' column in Windows Explorer GUI view on XP is always rounded to some "convenient" figure for display.
If you do 'Properties', it lists two sizes; viz, "Size" (the size of the actual file content) and "Size on disk" (the size of the disk allocation units used).
eg, I have a file where explorer lists the "Size" as "3K" in the GUI view and, in 'Properties, gives "Size" as "2.08KB (2,130 bytes)" and "Size on disk" as "4.00K (4,096 BYTES)"
So, depending on where you look, you can get 3 different numbers for the same file!
"a chunk size of 384 would be a very unlikely value"
Granted - that is true.
"it was a bug in the math of the programmer."
How about a bug in the assumptions of the user of that programmer? How about looking at the definition of the hex files?