CELF Project Proposal/Create tool to edit ihex or srec files

From eLinux.org
Revision as of 22:28, 14 December 2009 by Tim Bird (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Upgrade an existing Hex editor to be able to read/write Intel Hex and Motorola S-record files
Frieder Ferlemann


The ihex and srec formats can have an important role in an embedded developers toolchain. The formats specify both the addresses and the corresponding data, thus allowing to specify specific ranges of data which are to be modified. While editors for binary files exist for linux they all seem to lack import and export functionality for these formats.

Reading two files consecutively should result in a hexadecimal display like:

00000000 02 00 08 80 fe 75 81 07 12 00 78 e5 82 ... ..u....x.. 00000010 60 03 02 00 03 79 00 e9 44 00 60 1b 7a 00 90 00 `....y..D.`.z...

where the corresponding bytes are either highlighted (when the definition in the 1st file differs from the 2nd file), normal (if same), obmitted or greyed out (if there is no definition in either of the files), be in color1 if only defined in the 1st file and color2 if only defined in the 2nd.

Writing a selection of the buffer (lets assume byte 0x000b to 0x000f in the example above) to an .hex or .s19 file should be possible starting with offset 0x000b, 0x0000 or a user specified address.

If you own a mainboard/dvd-player/mouse/sound card/keyboard/ usb-device/graphics card/digital camera/microwave oven/mobile phone/ cdrom/car/pocket calculator/tv/modem/watch/printer/remote control/ washing machine it's likely that these file formats were involved.

Text tools (srecord, binutils) for these formats exist but might present an inhibition for developers which are used to a graphical toolchain on other platforms.

Embedded developers targetting these devices (especially 8-bit targets) typically do not use Linux as a host platform. If there is a win over then I'd hope for better linux support (f.e. upgrading the firmware of some of these devices would not require buying the license of another operating system) and I'd hope for more openness with respect to protocols and linux drivers.

An anecdotical contribution relating to the importance of having developers for a specific platform: http://www.youtube.com/watch?v=8To-6VIJZRE

In the long run it might be possible to interface to flashprogrammers.

Related work

* okteta   http://utils.kde.org/projects/okteta/
* srecord  http://srecord.sf.net
* others   http://en.wikipedia.org/wiki/Comparison_of_hex_editors

(* flashrom http://www.coreboot.org/Flashrom)

Related request: A five year old request for khexedit (predecessor of okteta), 20 votes http://bugs.kde.org/show_bug.cgi?id=94361

Persons to contact:

  • Friedrich W. H. Kossebau (okteta)
  • Peter Miller (SRecord)
2 weeks+ (depending on the internal structure of the hex editor)