Talk:Intel HEX

Clarification needed

The article makes a questionable statement "There are three types of Intel HEX: 8-bit, 16-bit, and 32-bit. They are distinguished by their byte order." Is that true? If yes please elaborate how you would distinguish these types merely on the byte order of the data or memory fields, especially if you don't know the data they contain and therefore cannot predict which order is correct/intended. As far as I can see you can only distinguish the three types by checking if they contain a 02 and/or 03 record (=> 16-bit), 04 and/or 05 record (=> 32 bit) or only 00 and possibly 01 records (=> 8 bit). 91.50.231.77 (talk) 18:56, 12 July 2011 (UTC)

Correction

Correction to one of the links format description

The link on the article page has been moved. JBadger169 15:09, 30 July 2007 (UTC)

It has been over 6 weeks since I posted this, no comments, will edit the main article. JBadger169 15:33, 24 September 2007 (UTC)

Byte Swap

The article says to beware of Intel 16 and Intel 32 which 'may' be byte swapped. Is there a reference to when it is swapped and when not swapped? 57.66.56.195 (talk) 11:24, 31 January 2008 (UTC)

According to the Intel specification the data must be in little-endian order. So the data would only be in big-endian (or other order) if an implementation has not followed the spec for some reason, which is sadly all too common. Non-standard behaviour should be specified in documentation for the particular tool, if at all. Btw, "byte-swapped" is a relative term and does not specify byte order, not really a good term to use in this context. Bobcousins (talk) 22:45, 18 August 2009 (UTC)

Out of curiosity, where in the Intel HEX specification does it say that the byte order is little endian? I'm looking at Intel's HEX specification here: [1] For data records (record type 00), it only specifies how bytes are transported. For byte-addressable machines, there's no notion of endianness at this level. Even so, the HEX specification is careful to state that the bits within the byte are written in big-endian order in the hexadecimal representation (high-order nibble first). For the records that define multi-byte quantities (record types 02, 03, 04, and 05), it specifies clearly that the high-order byte appears first and the low-order byte appears last, which is big endian ordering. Furthermore, the load offset that appears in every record is also big endian (high-order byte first).

Of course, this is a woefully underspecified format. For example, it doesn't say what to do if you encounter record types 02 and 04 in the same file, or more than one of 03 or 05.

Anyway, with regards to "may be byte swapped": I think it may be better to say that the Intel HEX format assumes a byte addressable memory and is specified in terms of such. When using HEX to program devices whose natural width is wider than a byte and may not be byte addressable, the device and its related tools specify what order the bytes are packed within its native word width. The Intel HEX specification is silent on such matters. --Mr z (talk) 17:53, 19 March 2010 (UTC)

Hmm, unfortunately I can no longer justify that assertion, although I felt sure at the time! It is possible that I found it somewhere else, or by inference from the spec which is designed for Intel chips (which were all little-endian at the time). Either way, I think I would have to withdraw it. I think everything you say is correct, although the byte order of fields in the HEX record does not really imply anything about the order of data being transferred. Bobcousins (talk) 12:05, 10 August 2010 (UTC)

Just In Case

If there is anyone keeping a close eye to the article's changes: I tried to make it more formal removing the 'Beware [...] some programmers tend to confuse [...]' part for another way of saying the same thing. Also removed the 'To make things more confusing' statement: although it is more friendly, it is not formal. —Preceding unsigned comment added by 200.88.113.34 (talk) 02:19, 5 January 2009 (UTC)

Record Separators

Looking at the original Intel specification, there is no standard for record separators. The example shows each record on a new line, and I've worked with an application that requires <LF> <CR> between each record. With the original punched cards this wasn't an issue, but is there a 'formal' definition of this. Just letting the records run on from each other doesn't work, even though the spec with fixed record lengths and a start character would seem to allow for this. The Yowser (talk) 16:48, 11 December 2009 (UTC)

Usage

"Intel HEX is a file format for conveying binary information for applications like programming microcontrollers, EPROMs, and other kinds of chips."

Can someone give concrete examples of Intel HEX application? Thanks, --Abdull (talk) 20:05, 9 March 2010 (UTC)

Like, how concrete? Here's an extremely specific example: I am developing software for a PIC24 microcontroller. The PIC24 tools output a Intel 32 HEX file. My PIC24 flash tool reads that HEX file and flashes it into the device. That's "programming microcontrollers" right there. In the past, I've used Intel 8 HEX files to download program images to an 8052-based development system, documented here, since that's what as31 output. --Mr z (talk) 15:17, 20 March 2010 (UTC)

checksum=0=FF?

"01, End Of File record, a file termination record. No data. Has to be the last line of the file, only one per file permitted. Usually every field except the record type (=01) and obviously the checksum field is zero, which gives ':00000001FF'."

I obviously fail to see the zero checksum field. Darsie42 (talk) 18:35, 21 September 2011 (UTC)

Color legend

Would it make sense to move the legend above Records? As things stand now, coloring is used in Records before the coloring scheme is defined, which could confuse some readers. Also, it might be helpful to show a simple colorized example of each record type in the records table, as is done with EOF (a "picture" is worth 1K words). Lambtron (talk) 15:30, 29 June 2014 (UTC)

I moved the legend. • Sbmeirow • Talk • 22:50, 29 June 2014 (UTC)

Thanks for rewriting my clunking text about line terminators. I copied your text over to the SREC (file format) article that I'm cleaning up. • Sbmeirow • Talk • 20:31, 30 June 2014 (UTC)

My pleasure. I've certainly written my share of clunking text. Often enough, though, it turns out to be a good starting point for coverage of important information (like line terminators). Lambtron (talk) 20:55, 30 June 2014 (UTC)

Capatilization

Why is HEX capitalized? It is not an initialism, and the Intel specification does not capitalize it, nor does the libbfd source code (as used in, e.g., objcopy). — Preceding unsigned comment added by 24.230.78.190 (talk) 23:21, 2 March 2016 (UTC)

Because it's the file extension? (I'm not mocking you or anything, I don't know either) SIGSTACKFAULT (talk) 14:13, 9 July 2019 (UTC)

Record Types needs links

The Record Types section needs links to relevant wiki pages. At work, may do later if I remember ;) SIGSTACKFAULT (talk) 14:11, 9 July 2019 (UTC)

"Start Segment Address" is actually the starting execution address

Although the original Intel document states that the 03 record type is "Start Segment Address" the description more correctly states "initial content of the CS:IP registers"

This is actually the starting execution address.

I don't know how this should be noted in the article.

DGerman (talk) 21:35, 22 July 2019 (UTC)

I added a comment to the Record Types table. Lambtron talk 00:27, 23 July 2019 (UTC)

Addition question

It seems like the sum is wrong for this calculation: 03 + 00 + 30 + 00 + 02 + 33 + 7A = 1E2

should it be just E2? Or, am I missing a subtlety about 2s compliment? — Preceding unsigned comment added by Rutabaega (talk • contribs) 23:31, 8 January 2020 (UTC)

 Done - it was wrong, I fixed it. • Sbmeirow • Talk • 23:57, 8 January 2020 (UTC)

History section includes cite warnings

I have rephrased some of the history section. There remain cite warnings. The referenced, archived, very large manual pages 6-75 begins the discussion of format DGerman (talk) 00:01, 28 October 2021 (UTC)

Quoting in reference section is out of control

Quoting in reference section is out of control. It is way too long. Either shorten it and/or remove it. • Sbmeirow • Talk • 17:01, 21 October 2023 (UTC)

I asked help desk about this reference section, see response at Wikipedia:Help desk#October 22 (and edit). • Sbmeirow • Talk • 03:24, 22 October 2023 (UTC)

non-binary media such as paper tape, punch cards,

Both paper tape and punch cards can surely present "binary" data.

Suggest this be removed.

DGerman (talk) 00:55, 22 October 2023 (UTC)