Searching \ for 'Interpreting .HEX Files?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=interpreting+hex
Search entire site for: 'Interpreting .HEX Files?'.

Truncated match.
PICList Thread
'Interpreting .HEX Files?'
1998\07\09@201709 by Mike Hamilton

picon face
I have been trying to figure out how to read .hex files created by the mpasm
compiler.  Does anyone know how to interpret them or where I could find the
info?

1998\07\09@204148 by Jerry Meng

flavicon
face
At 04:08 PM 7/9/98 -0700, you wrote:
>I have been trying to figure out how to read .hex files created by the mpasm
>compiler.  Does anyone know how to interpret them or where I could find the
>info?

Hi Mike,

If your MPASM is a windows version, I am sure you can find the info
in the help, where
----------------------------------------
Appendix A.  Hex File Formats

Introduction
Highlights
Hex File Formats
----------------------------------------

Good Luck

Jerry

1998\07\09@210046 by ssj

flavicon
face
Jerry Meng escreveu:

> At 04:08 PM 7/9/98 -0700, you wrote:
> >I have been trying to figure out how to read .hex files created by the mpasm
> >compiler.  Does anyone know how to interpret them or where I could find the
> >info?

if you want i've done a dos program to convert .hex files to plain binary format
,

to send to an eprom...

1998\07\10@084801 by Peter L. Peres

picon face
On Thu, 9 Jul 1998, Mike Hamilton wrote:

> I have been trying to figure out how to read .hex files created by the mpasm
> compiler.  Does anyone know how to interpret them or where I could find the
> info?

Hex files for PICs on Intel are raw binary data. Since each word on a PIC
takes more than one byte, they are packed in two bytes each, with some
bits unused.

To edit the file, use a hex editor (ex: Norton Diskedit will do that). To
make sense of them, you need a simulator or a disassembler. The simulator
can execute such a file directly, the disassembler can turn it into source
code (assembly) minus the symbols.

Peter

1998\07\10@124908 by Paul BRITTON

flavicon
face
On Thu, 9 Jul 1998, Peter L. Peres wrote:

>
>Hex files for PICs on Intel are raw binary data. Since each word on a PIC
>takes more than one byte, they are packed in two bytes each, with some
>bits unused.
>
>To edit the file, use a hex editor (ex: Norton Diskedit will do that). To
>make sense of them, you need a simulator or a disassembler. The simulator
>can execute such a file directly, the disassembler can turn it into
source
>code (assembly) minus the symbols.
>
>Peter

.HEX files are not in raw binary form, they are ASCII format, each line
being a data record,terminated in a CR/LF, with the following format:

:BBAAAATTHHHHHHHH......HHHHCC

Where:
BB     Two digit hex byte count representing the number of data words
that will appear on the line.

AAAA   Four digit hex address representing the starting address for the
data record.

TT     Two digit record type that will always be '00' except for the
end-of-file record which is set to '01'

HH     Two digit hex data word

CC     Two digit hex checksum that is the two's complement of the sum of
all preceding bytes in the record including the prefix bytes.


The format was originally for 8 bit data (INTEL Intellec 8/MDS Format) but
has been extendeed for 12,14,16 bit data words by having two bytes for
each address location, in low byte,high byte order (little endian).


So if you open this with a hex editor you will see something like:

3A 31 30 30 30 30 30 30 30 47 42 30 34 ............  :10000000FA04.......

Which, while not being impossible to work with, is probably not the best
way to do it, just use Notepad, Wordpad, DOS Edit, Edlin or better still
PFE or WINedit, you can even use Word, but I'm not a masochist!


TTFN

Paul

1998\07\10@154115 by Peter L. Peres

picon face
On Fri, 10 Jul 1998, Paul BRITTON wrote:

> .HEX files are not in raw binary form, they are ASCII format, each line
> being a data record,terminated in a CR/LF, with the following format:

My impression was, that .HEX files are raw images (.HEX == .BIN). You may
be right, though. Anyway, most reasonable tools call this format 'object
format', and give it an extension of .OBJ or .S19...

> The format was originally for 8 bit data (INTEL Intellec 8/MDS Format) but
> has been extendeed for 12,14,16 bit data words by having two bytes for
> each address location, in low byte,high byte order (little endian).

imho, wrong. The default .OBJ file output by PICALC under DOS is INHX16
which is big endian. The INHX8M is the little endian version (and it
confused the hell out of the 1st parser I wrote for .OBJ files - the only
way to automatically tell the type is rewriting, as the checksum applies
correctly for each line if you swap the bytes around).

> Which, while not being impossible to work with, is probably not the best
> way to do it, just use Notepad, Wordpad, DOS Edit, Edlin or better still
> PFE or WINedit, you can even use Word, but I'm not a masochist!

How can these edit 8-bit codes ? I think that all Windows programs will
pop up something (a fuse ?) sooner or later as you try entering secret
codes <G>.

Peter

1998\07\13@064147 by Caisson

flavicon
face
> Van: Mike Hamilton <spam_OUTmikeh9TakeThisOuTspamEARTHLINK.NET>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: Interpreting .HEX Files?
> Datum: vrijdag 10 juli 1998 1:08
>
> I have been trying to figure out how to read .hex files created by the
mpasm
> compiler.  Does anyone know how to interpret them or where I could find
the
> info?

Yes, someone does :-)

It's (if I'm not mistaken) the Intel HEX-format

See below:

: 10 0150 00 8F0D900D901010158E010C1703100800 D4
|  |     |      |     |
   |
|  |     |      |     |
   \- Checksum
|  |     |      |     \- data-bytes
|  |     |      \- Record -type (00 - Data, 01 - end-of-file)
|  |     \- Storage-adress (divide by two for 14/16 bit cores)
|  \- Number of DATA bytes
\- Start char

Checksum :  Subtract ALL hex-bytes from 0x00 (including the Checksum-byte)
the result should be 0x00 (Or add all bytes EXCUSIVE the checksum.  It
should than _match_ the checksum)

CTRL-chars in front/back are ignored (CR, LF,TAB,SPACE).

Want/need to know more ?  Let me know.

Greetz,
 Rudy Wieser

1998\07\13@200743 by Sean Breheny

face picon face
Hi Peter and others,

Actually, the standard Intel .HEX format is NOT raw binary data. It
consists of ASCII text numerals and letters which represent hex numbers, i.e.

A0B355

would be the hex number A0B355, just as it looks. Therefore, you can view
the file in any text editor, you should not need a hex editor. The .HEX
files produced by MPASM, I think, also follow this standard, but I cannot
be 100% sure since I do not usually use MPASM.

I am at work right now, but at home I have a file which describes the
.HEX format. I got it off the web. IF you do a search, you will probably
come up with it.

Good Luck,
Sean




On Fri, 10 Jul 1998, Peter L. Peres wrote:

{Quote hidden}

1998\07\14@004858 by paulb

flavicon
face
Peter L. Peres wrote:

> My impression was, that .HEX files are raw images (.HEX == .BIN).

 No, that's exactly the point; .HEX =/= .BIN  Very specific here.

> Anyway, most reasonable tools call this format 'object format', and
> give it an extension of .OBJ or .S19...

 I'm not sure about the .OBJ bit.  While the .HEX format has much
embedded information; addresses for isolated segments, "type" fields and
"run" addresses, I understand .OBJ format has much more, linking data to
be specific.  And this format can *not* be .S19 for the very simple
reason - it *isn't* S1/S9 format!

> The default .OBJ file output by PICALC under DOS is INHX16 which is
> big endian.  The INHX8M is the little endian version (and it
> confused the hell out of the 1st parser I wrote for .OBJ files - the
> only way to automatically tell the type is rewriting, as the checksum
> applies correctly for each line if you swap the bytes around).

 Well, sounds like you *have* looked into this bit!

> How can these edit 8-bit codes?  I think that all Windows programs
> will pop up something (a fuse ?) sooner or later as you try entering
> secret codes <G>.

 But .HEX files do not *contain* 8-bit codes.  They are totally 7-bit
*text* in which control characters have their ASCII meaning.  Indeed,
any ASCII editor will edit them just fine.  You can edit the hex to
alter the 8-bit values it *represents* as long as you fix the checksum
accordingly.
--
 Cheers,
       Paul B.

1998\07\14@023335 by Dr. Imre Bartfai

flavicon
face
Only format correction:

The spaces in the muster line don't exists. They are inserted here only
for the sake of readibility. All numbers are to be interpreted in hex.

If one wants to edit that line, the checksum and possibly the length field
must be maintained. The change in the length can affect the storage
address field also. So I advice to follow the following schema:

1. Read in and interpret all data in a contiguous storage area.
2. Edit this storage area as you want.
3. Write out it in the appropriate format.

Imre


On Mon, 13 Jul 1998, Caisson wrote:

{Quote hidden}

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...