hex and bin

[radium98]

Hello
i have two files that are needed to work on a device . they are in demo version .
i have to use pony prog . i am familiar in burning hex into pic , but not attiny2313 .My question is should i have to put both files .bin and .hex to get it to work .
thanks.

 

[betwixt]

Normally, the bin and hex are the same file but in different formats. Bin is the actual bytes that go into the device memory and hex is the same bytes but in ASCII with address headers to say where in memory the data is to be loaded. There is no reason why both can't be used and in some cases the program is in hex but additional tables or configuration is in bin format.

Brian.

 

[radium98]

Normally, the bin and hex are the same file but in different formats. Bin is the actual bytes that go into the device memory and hex is the same bytes but in ASCII with address headers to say where in memory the data is to be loaded. There is no reason why both can't be used and in some cases the program is in hex but additional tables or configuration is in bin format.

Brian.

Thank you Brian . i have burned the hex file only but the device did not work , so why i ask shou i also put the bin file in , and then is the process . i have tried to search some infos before i posted , but i get stacked because i saw two files .

 

[FvM]

I can imagine cases where two files are programmed to a device, e.g. program and data, but it's rather unusual.

I would inspect file content to understand if one or both are valid executable code, or possibly just identical.

 

[betwixt]

The MCU actually contains binary data (= bin file) but most programming software accepts a text representation of it (= hex file) and converts it to binary during the programming process.

The problem with bin files is they can contain any value from 0x00 to 0xFF so there are no 'spare' numbers or characters to be used for special purposes. Taking an extreme example, suppose you had data to put in 1Mb of memory but only the first and last address held anything, your bin file would have to be 1Mb long and the middle of it would be irrelevant.

In a hex file, the data is presented as text characters using ASCII values and split into short lines. Each line follows an agreed format, sadly there is more than one but by far the most common is "Intel hex" . All lines start with a colon then the next few characters describe the data type and the address in the device it is to be loaded into then the data itself and finally a checksum to verify the integrity of the line. All addresses and data are stored as human readable ASCII characters so for example, binary numbers 01 23 45 would be 30 31 32 33 34 35 because those are the ASCII codes for the individual parts of the binary values. The programming software splits the parts of the line to extract the address, data and checksum to verify it then convert it to binary values.

The big advantage of hex files are they carry the address where the data is to be located when put in the devices memory. So using that 1Mb example again, instead of a 1Mb long binary file containing mostly wasted space, the hex equivalent would be one line with the first address and the data byte and a second line with the last address and the data byte. It is far more efficient, especially on large files and ones where data or program is stored in several blocks rather than a single contiguous one.

If you look at your file in a text editor, if it looks like lots of lines starting with a colon ":" and then a string of characters between 0 and F it will be a hex file, if it looks like a jumble of odd symbols and characters it is probably a binary file. It would be very unusual to load a hex file directly into MCU memory!

Brian.