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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
Usage
"Intel HEX is a file format for conveying binary information for applications like programming microcontrollers, EPROMs, and other kinds of chips."